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Introduction 


Introduction 

The information herein is current with regard to the following program 
revision levels: 

CCONTROL — S0006.E02.005 (002) 

ECONTROL — S0014.E02.005 (002) 

LGEN — S0063.E01.002 (002) 

This manual is intended to provide you with an understanding of the use 
of the directory filtering process. It is directed to users who will define 
filtering methods for themselves and other users. For detailed discussions 
of the select and reject commands see System/55 Report Generation 

(S55-013). 

Directory filtering is most useful for limiting directories in ways that are 
not possible with available keys and paths or with the__user directory 
methods defined with rcMoi nmthrough icmdI CHq] (see ET/960 Editorial 
User’s Manual, S 55 - 017 ; and ET/960 Classified User’s Manual, S55-015). 
Filtering allows you to further delimit a directory of stories, ads, and so on 
by keying on specific Q-fields. 

Directory filtering methods are not limited to use on story or ad 
directories. They may be used on any list of any data file. 

Please refer to the Index of Record Structures (S55-007) for instructions 
on listing Q-fields and information on data structures. 

Filtered Directories and Indexes 

Directory filtering allows you to limit directories and indexes to the 
stories (or records) with which you are most concerned. The Key field of 
the directory or index prompt allows you to specify the beginning point of a 
directory, a specific item, or items beginning with specified characters. 
That, of course, is a kind of filtering. With the path and key alone, however, 
you may not specify a range within which items are to be listed (except by 
key name with the asterisk) or filter based upon the contents of a field 
other than the key. That additional capability is provided by the directory 
filtering feature of System/55. 

Directory filtering is accomplished by specifying the name of a method 
(the name of a special story containing the details of the method) in a 
Directory command, or in an Index command. The method affects only 
that directory or index. Keep in mind that the filtering method is in addition 
to the path and key specified in the Directory prompt. A filtering method 
need not be specified, but it may not be specified alone (without a path or 
key). 

A previously defined filtering method may also be specified when 
building a list with lgen (see Form Generation and List Generation, S55- 
ooi). This establishes a permanent relationship between the name of a list 
and a filter. In that case the filter is enabled each time the list name is used 
in a directory or index prompt. 
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A directory filtering method may be simple or complex. By looking at 

various fields in story headers, it eliminates stories that do not meet speci¬ 
fied criteria. 

Editorial Examples 

• A method assists you in selecting wire stories by limiting a directory to 
stories entered today and which also fall within a range of lengths. 

• Lists only remote input stories (Teleram, Sportscomm, etc.) filed within 
the last three hours that have not yet been edited or assigned to a page. 

• Stories in a desk from a specified wire service, with a specified topic, but 
excluding deferred, advance and Sunday advance stories. 

• All flashes, bulletins and urgents that have been received in the last 20 
minutes. 

• Only stories that have outstanding spelling errors and/or justification er¬ 
rors and/or have never had Spellbinder run and/or have never been 
justified and/or have been edited since Spellbinder or justification. 

• All stories assigned to a page (or to a section) which have not been 
released. 

• All stories authored or edited by a specified user that have not been 
assigned publication dates. 

Classified Examples 

• All ads for a specific customer (path «na») that have start dates 
beginning on a specified date. 

• Ads in a classification (path «cl») using a specified alternate telephone 
number, not the primary number referenced by path «ph». (A good 
application for a template take to allow users to enter the number in 
which they are interested.) 

• All ads in a classification starting, or stopping, on a specified date. 

• All killed ads in a classification (status «k») with outstanding balances. 

• Only ads in a classification, of a particular type, more than 3 lines, that 
are starting tomorrow or later. 

• Ads entered by a specific author (path «au») with a total cost of $20 or 
greater. 

• Only ads for a particular classification that are running for 5 or more 
days. 

• Ads in a classification that have been changed by a specific user today. 

• Ads (in a classification, for a customer) that have been killed in the last 2 
days. 

• Only ads for a specified classification, in a specified shopper (or edition), 
running on a specified date, that have a total cost of $5 or more. 
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Section 1 

Defining Directory 
Filtering Methods 

The large number of available Q-fields for various files precludes the use 
of a standardized form for directory filtering. However, the take in which 
the directory filtering method is compiled may be a template take (see 
“Template Takes for Directory Filtering Methods”), providing a user- 
definable “form.” 

Directory filtering, like rgen, uses select, reject and sort 
statements. A maximum of 10 select/reject and 10 sort statements per 
filtering method is allowed. With the exception of “wildcard” strings and 
constants referencing Q-fields (see “Constants” and “Use of the Trailing 
Wildcard”) the case of the characters is unimportant. Typesetting 
commands such as g or H should not be used to end lines when specifying 
directory filtering methods. 

The Output field of the header may be cleared to prevent accidental 
justifying and filming. Takes containing filtering methods may be made 
templates or “read only” as an additional precaution against inadvertent 
changes. 


Identifying Filtering Methods 

Once the desired commands have been entered, give the take an easily 
remembered story name or number. You may find it helpful to describe the 
function of the filter in the guide of the header. This will enable users who 
are unfamilar with rgen syntax to see immediately what the results of 
enabling a particular filter will be. 

Additional comments can be embedded in the filtering method as 
necessary to provide a complete description of its function. When an 
exclamation mark (!) is entered in the take containing the filtering method, 
all text which follows (to the end of the line in which it occurs) is ignored. If 
comments are inserted in the first line(s) of the filtering method, they can 
be displayed in a long directory. 

It may also be desirable to place all directory filtering methods in a 
single basket (or desk) as illustrated in Figure 1-1, so that they may be 
easily referenced. In this way, users can see each method and its function 
when using a list style which displays the guide. 


Story Directory With Guide (BA,FILTER) 10/12/81 13:41 

Story name Guide 

short story Selects stories shorter than 6 inches which haven' 
wire filter Selects stories with wire priority U and guide AM* 
PM filter Selects stories entered after 12:30 

3 Items listed 


Figure 1-1. Directory of Directory Filtering Methods. 


1.1 










Defining Directory Filtering Methods 


Directory Filtering 


A long directory of the basket will display any comments embedded at 
the beginning of the take (Figure 1-2). 


Story Directory With Guide (BA,FILTER) 10/12/8113:41 

story name Guide 

short story Selects stories shorter than 6 inches which haven' 

!use this filter to select potential fillers 
select length < 6 and filnfstatus <> "F" 


vvvvwvvv w>A^VVVVVW^VVVVVVVVVV\^A^A^V\A^W^A^V^VVVV^V\^\^VVVVVWA^WAAAAAAA^VVWAAAAWl 

Figure 1 -2. Long Directory of Directory Filtering Methods with embedded comments. 


Select and Reject Commands 

select or reject statements must precede any sort statements in the 
filtering method. The select and reject commands specify that input 
records are to be selected or rejected (filtered) based on the contents of 
fields in the records. 

The commands are entered in the following fashion: 

SELECT (expression) 

REJECT (expression) 

Expressions are always evaluated to a single true/false value (see 
“Selection/Rejection Logic,” below). An expression may be numeric or 
alphanumeric. Alphanumeric strings are enclosed in opening quotes 
(shift of quote key). 

The expression may consist of a single field, a constant, a simple 
expression, or it may be a series of conditions which are tested to select or 
reject a record. 

Expressions consist of operands separated by arithmetic, relational and 
logical operators. 

An operand may be one of the following: 

1. a field from the record of the file specified with the file command. 

2. a constant expressed as an integer («50»), 

3. a specific date (11/15/81) or a specific time (13:00). 

4. the keyword «today» (the current date) or the keyword «now» (the 
current time). 

5. The keyword «me» (the name of the current user). This keyword can be 
useful in writing general filters. To provide a user with a list of stories 
which he last changed, you need not write a different filter for each 
user. For example: 

SELECT previous'user = me 

The arithmetic operators (numeric fields only) are: 

+ Add * Multiply 

Subtract (hyphen) / Divide 
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The relational operators test for a relationship between two arithmetic 
values. They are as follows: 

= Values of the operands are equal 
< Left value is less than right value 
> Left value is greater than right value 

< = Left value is less than or equal to right value 

> = Left value is greater than or equal to right value 
<> Values are not equal 

The logical operator “and” is a conjunction used to express multiple 
conditions, all of which must be true for the expression to be true: 

SELECT page'date = TODAY AND edition = "oc" 

The logical operator “or” is a conjunction used to express alternate 
conditions, any of which may be true for the expression to be true: 

SELECT wire'priority = "F" OR 
wire'priority = "B" OR 
wire'priority = "U" 


The logical operators may be used to string true and false tests in a 
single expression: 

SELECT entry'date = TODAY OR 

entry'date = TODAY - 1 AND 
wire'priority = "A" 

Expressions are evaluated from left to right. Precedence is given to 
operators in the following sequence: 1) arithmetic operators, 2) relational 
operators, 3) logical operator «and», and 4) logical operator «or». Higher 
precedence items are evaluated first. Precedence specification, through 
the use of parentheses «(....)», is not recognized. 


Selection/Rejection Logic 

1. If the expression is true, the record is selected or rejected according to 
the command specified (select or reject) and all subsequent select/ 
reject commands are ignored. 

2. If the expression is false, the next select/reject command, if any, is 
examined. 

3. If the last select or reject command is examined and found to be 
false, the opposite function is performed. 

Classified Example: 

SELECT stop'date >= TODAY AND stop'date < TODAY + 4 

The header records of all ads that will stop running within the next four 
days, including today, will be selected. This is the equivalent of: 

REJECT stop'date < TODAY OR stop'date > TODAY + 4 

Generally, it makes more sense to select a small group of records from 
a large file, rather than to reject all records that do not meet limiting criteria. 
However, it makes no difference and the technique you use should be the 
one that is most consistent with your point of view. 
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Editorial Example: 

REJECT entry"date < TODAY - 7 

SELECT last A time = 0 OR last^time > NOW -24h 

The header records of all stories entered in the last week which have 
never been modified or haven’t been modified in the last 24 hours will be 
included. In this case, the order of the commands is important. If the 
select command were encountered first and found to be true, the reject 
command would be ignored and the objective would not be met. As it 
stands, the select command is only interested in those records passed 
over by a false reject test. 

The Sort Command 

The sort command allows you to specify how the filtered directory will 
be sorted before it is displayed. It must be entered following the select/ 
reject statements (if any). 

The command is entered in the following fashion: 

SORT BY (field name) [FOR (count)] [UPPER] [DESCENDING] 

by —the name of the Q-field by which the records are to be sorted. At least 
one field must be specified. Up to 10 fields may be specified, 
providing the capability for detailed embedded sorting, ranging from 
most major to most minor. 

for —(optional) The number of characters in the specified Q-field which 
are to be checked for sorting. This allows sorting on less than the total 
number of allowable characters in the field to save space in the file 
(see “Considerations When Specifying Sort Methods”). For example, 
limiting a sort by guide to 8 characters (rather than allowing the full 
64) could make a substantial difference in the number of directory 
items displayed. 

A method may be specified for each by field. If none is specified, the 
default is «logical ascending®. This sequence includes the standard 96- 
character ascii character set. The default may be overridden by one or 
both of the keywords described below: 

upper —causes the case of alpha characters (A versus a) to be ignored in 
the sort. Meaningless for numeric fields. Without this keyword 
uppercase is sorted first then lowercase. 

descending —overrides the ascending default, causing records to be 
sorted in descending (reverse ascii) order. 

Examples: 

REJECT ... REJECT . . . 

SELECT . . . SELECT . . . 

SORT BY desk'name SORT BY desk"name 

BY topic BY basket'name 

BY keyword BY author 

BY guide FOR 8 UPPER BY story'name 

UPPER 

The example on the left will produce a directory sorted first by desk, and 
within each desk by topic, then by keyword, then by the first eight 
characters of the guide. «upper» is specified in order to achieve a truly 
alphabetical sort regardless of the use of upper- or lowercase in the guide. 
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The example on the right sorts a little differently. The story name uses 
the «upper» option for the same reason; without it, the records would be 
sorted by uppercase, then by lowercase—the normal sequence. 

Considerations When Specifying Sort Methods 

The following is of interest and use primarily to those who are familar 
with structures and files in the system. This is a description of the events 
which occur when you request a directory and specify a filtering method 
which contains a sort method. 

1. The priority of the process making the request is lowered by one. 

2. All records which the pass the select/reject statements are read 
until there are no more records in the directory or until the limit on the 
number of records which can be sorted is reached. (The method by 
which this limit is computed is explained later.) As a record is selected, 
an extract containing sufficient information to later sort the record is 
recorded. 

3. Once all extracts have been prepared, the extract list is sorted as 
specified by the user in the sort method. This operation is performed 
in memory and does not involve using the disk. 

4. The extract list is compressed to a list of “primary keys” thus recording 
the minimum amount of information which is required to retrieve the 
records in the specified order. 

5. The priority of the process making the request is restored to its original 
value. 

6. The sorted list of extracts is used to display the directory in a normal 
manner. 

Requesting a sorted directory causes considerable system overhead 
since all items which are going to appear in the directory must be read 
twice, once to select the item and create an extract and a second time to 
display the item in the directory. Redundant sorting requests are not 
detected. For example, requesting to sort a basket by story name when 
the default sequence of the basket is by story name. 

Selection and Sorting Limits 

There is a limit on the number of items which can be selected and 
sorted, determined by computing two limits. To perform these computa¬ 
tions, you need some knowledge of the nature of the data file which is 
going to be sorted and of the fields which define the records in the data file. 

There are 6,144 bytes of cpu memory available for building the extract 
file during the selection and sorting phase. The size of the extract record is 
the sum of the lengths of the fields specified in the by clauses in the sort 
statements plus the length of the “primary key” to the file. (The length of a 
field can be shortened by using the for parameter [described above] of 
the sort command, thus shortening the length of the extract.) The first 
limit is 6,144 divided by the size of an extract record—the number of 
extract records which can be stored. 

The memory area available for the compressed list of “primary keys” is 
2,048 bytes. Since this list contains only “primary keys”, the limit on the 
number of entries is 2,048 divided by the size of the primary key to the file. 


1.5 




Defining Directory Filtering Methods 


Directory Filtering 


The maximum number of entries that can be selected when sorting (and 
hence the maximum size of a sorted directory) is the minimum of the two 
limits above. As an example, the primary key to the header file is 4 bytes 
long. The number of primary keys which can be stored is then 512 (2048 
divided by 4). If we were to sort on the author field (12 bytes long), our 
extract file could hold 384 records (6144 divided by 12 + 4) and hence the 
directory would be limited to 384 records (the smaller of 512 and 384). 

Implementation Examples 

Using directory filtering, you can limit directories to only those items in 
which you have a specific interest. Let us suppose, for example, that you 
are looking for a sports story (stories) less than six inches long which has 
not been filmed. An ordinary directory of the Sports basket will list many 
stories in which you have no interest. You must go through the directory 
checking each story to see if it meets your needs. 

With a directory filtering method like the one illustrated in Figure 1-3, 
you may limit the directory of the Sports basket to those stories in which 
you are interested. 


FORM 9/24/81 12:54 

Changed by WHITNEY on 9/21/81 at 8:23:39 
Created by WHITNEY on 9/01/81 at 12:54 
Status E, 2 lines, 70 chars 

Story short story Topic _ Keyword _ 

Basket FILTER _ Desk _ Author WHITNEY 

STYL _ Output _ (_) Template _ Private? R 

Pub Date _ Page __ Expires _ At _ 

Destination _ When Filmed? _ Send @ 0: 00 

Selects stories shorter than 6 inches which haven't been filmed 

select length < 6 and film'status <> "F" 
sort by keyword for 5 

VVVVV^AAAAA/V^AA/VVVVA/V^A/VVVVVVVVVVVVVVVVVVVV^AA/VV^A/VVVVVVVVV^AAAAA/VVVVV^AAAA^AAAAAAAAAAAAAAA/VVVVVVVV , 

Figure 1-3. Sample Directory Filtering Method. 


The first line specifies that this directory filtering method will select only 
those stories which are shorter than 6 inches and have not been filmed. 
The second line specifies that the items be sorted by the first five 
characters of the keyword. Since the order was not specified the directory 
will default to ascending. An example of the use of this filtering method is 
illustrated in Figures 1-4 and 1-5. 


Wire Story Listing (BA, 

SPORTS) 



9/24/81 8: 

05 

Keyword 

Basket 

Topic 

P 

Author 

Entry 

time 

Lns 

FIGHTS 

SPORTS 

LIGHTWEIGHT 

D 

APS136 

9/24 

8: 02 

98 

FOOTBALL 

SPORTS 

NFL SCORES 

R 

APS165 

9/24 

8: 00 

34 

FOOTBALL 

SPORTS 

AFL SCORES 

R 

APS160 

9/24 

7: 56 

42 

BRIEFS 

SPORTS 

WEDNESDAY 

D 

APT199 

9/24 

7: 50 

30 

SPORTSVISION 

SPORTS 

CABLE 

R 

APH224 

9/24 

7: 45 

27 

FIGHTS 

SPORTS 

WEDNESDAY 

D 

APS104 

9/24 

7: 40 

10 

HOCKEY 

SPORTS 

NHL 

R 

APH225 

9/24 

7: 39 

13 


VVVVVVVVVV^AAA/V\AA/VVVVVV^A/V^A/V^A/VV^A^VVVV\A/^/\AA/VVV^AAAAA/V^/^^VVVV^A/VV^AAAAA/VVVVVV^A/V^AA/V^AAAAAA/VVV , 

Figure 1-4. Short Directory Following Path «ba», Key «sports», List «wire». 
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Figure 1 -4 illustrates the directory as it would normally appear. In Figure 
1-5, the directory has been filtered by the method illustrated in Figure 1-3. 
Only unfilmed stories less than 6 inches long are displayed. 

If this were a regular application a special list style could be designed 
with lgen which names “short story” as the filtering method. 


Wire Story Listing (BA, SPORTS), sorted 9/24/81 8:10 


Keyword 

Basket 

Topic 

P 

Author 

Entry time 

Lns 

BRIEFS 

SPORTS 

WEDNESDAY 

D 

APT199 

9/24 

7: 50 

30 

FIGHTS 

SPORTS 

WEDNESDAY 

D 

APS104 

9/24 

7: 40 

10 

HOCKEY 

SPORTS 

NHL 

R 

APH225 

9/24 

7: 39 

13 

SPORTSVISION 

SPORTS 

CABLE 

R 

APH224 

9/24 

7: 45 

27 


4 Items listed 

VVVV\Al\A/VVVVVVVVVVVVVXVVVVVVV\AA/\A/VVVV\/V\A/^AAA/VVVVV^A/V\^/VVVVVVVVVVVVVVVVVVVVVVVVV\AA/VVVVVVV\A/VVVVV , 

Figure 1-5. Short Directory Following Path «ba», Key «sports», List «wire» filtered by “short story”. 

Use of the Trailing “Wildcard” 

Directory filtering allows you to limit the comparison the system makes 
on the constant. If you include a trailing asterisk in the string field constant, 
the comparison is shortened to the length of the constant, excluding the 
asterisk. In effect, the asterisk acts as a trailing “wildcard.” This is identical 
to its use in the key field of a Directory of Index prompt. 

If the asterisk is embedded in the string, for example “a*m”, it is not 
treated as a wildcard and the filtering method will select only exact 
matches (in this case stories with guides 

The directory filtering method illustrated in Figure 1-6 will match on all 
stories with a wire priority of “u” and a guide beginning with “am”. The 
selected stories will be sorted by the first 10 characters of the guide in 
“true” (no regard for case) descending alphabetical order. 


FORM 9/24/81 12:54 

Changed by WHITNEY on 9/20/81 at 9:39:23 
Created by WHITNEY on 9/14/81 at 12:54 
Status E, 2 lines, 43 chars 

Story wire filter Topic _ Keyword _ 

Basket FILTER _ Desk _ Author WHITNEY _ 

STYL _ Output _ (_) Template _ Private? R 

Pub Date _ Page _ Expires _ At _ 

Destination _ When Filmed? _ Send @ 0: 00 

Selects stories with wire priority U and guide AM*_ 

select wire'priority = "U" and guide = "AM*" 
sort by guide for 10 upper descending 

VVVVVVVVVVVVVVV^A/V\A/VVVVVVVVVVVVVVVVV\AAA<VVV^A/^A/V\AA/VVVVVVVVVVVVVVVVVVV\AAA/VVVVVVVVVVVV\A/V\A/\AAA/VV , 

Figure 1-6. Directory Filtering Method Using “Wildcard”. 

The Universal Match Character 

The universal match (logical not) character — «-,», in the triple shift 
position on the spacebar, may be used in directory filtering string 
comparisons. It acts as an embedded wildcard, matching on any 
character in the indicated position (just as it does when used for search 
and replace during text editing). 
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The select statement below would select all stories with a topic 
containing the letters “ail” beginning in the second position, (“sail” or “rail” 
for example). The asterisk limits the comparison to the first four letters of 
the topic. Thus, “sailing” or “railroad” might also be selected. 

SELECT topic = "-.ail*" 

Constants 

Constants being compared to fields which are defined as uppercase 
only (for example author, basket, topic, and keyword) will be 
converted to uppercase if they are entered entirely in lowercase. If the 
constant contains both upper- and lowercase characters it will not be 
converted. All statuses are converted to uppercase. Wire priorities, 
however, are not converted. 

(The wire services currently send all priorities as uppercase. However, 
they have reserved lowercase for future use. It is for this reason that 
wire'priority is not defined as an uppercase field.) 

Use of Decimals 

Directory filtering allows the use of decimals when specifying a value (as 
when testing for story or ad length for example). The number of decimal 
places may not exceed that specified in the field’s edit code. 

Rules for Specifying Dates 

A date may be specified as a series of integers separated by slashes: 
mm/dd/yy or mm/dd (current year assumed). A date may also be specified 
using the keyword today and the arithmetic operators for addition (+) or 
subtraction (-). For example: today - n or today + n. 

Rules for Specifying Time 

The time portion of a double integer date/time input in the form xx:yy is 
interpreted as hours and minutes, not minutes and seconds. 

A number in the form xx:yy:zz is interpreted as hours/minutes/seconds. 

A number with no colons is interpreted as an interval in minutes. 

A number with no colons but followed by ‘H’ or ‘h’ (case is unimportant) 
is interpreted as an interval in hours. 


FORM 9/24/81 12:54 

Changed by WHITNEY on 9/05/81 at 9:24:45 
Created by WHITNEY on 9/04/81 at 10:54 
Status E, 2 lines, 54 chars 

Story PM filter Topic _ Keyword _ 

Basket FILTER _ Desk _ Author WHITNEY 

STYL _ Output _ (_) Template _ Private? R 

Pub Date _ Page _ Expires _ At _ 

Destination _ When Filmed? _ Send @ 0: 00 

Selects stories entered after 12:30_ 

reject author = me 
select entry^time > 12:30 

^^^^^^^^^vw\aavwvwvwwwvww\w\a/wvwv\aaa/waaaa\wv\^aawvwvwww\aaaaawaaaaaaaaaaaa^ 

Figure 1-7. Directory Filtering Method Specifying Time. 
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The directory filtering method illustrated in Figure 1-7 selects stories 
entered since 12:30 except those entered by the current user. 

The filtering method illustrated in Figure 1 -8 will select stories entered in 
the last week which have never been modified or haven’t been modified in 
the last 24 hours. 


FORM 9/24/81 12:54 

Changed by WHITNEY on 9/12/81 at 11:14:23 
Created by WHITNEY on 9/02/81 at 14:30 
Status E, 3 lines, 104 chars 

Story unmod filter Topic _ Keyword _ 

Basket FILTER _ Desk _ Author WHITNEY 

STYL _ Output _ (_) Template _ Private? R 

Pub Date _ Page _ Expires _ At _ 

Destination _ When Filmed? _ Send @ 0: 00 

Selects stories entered in last week and unchanged in last 24hrs 

reject entry'date < today - 7 

select last'time = 0 or last A time < now - 24h 

sort by topic for 6 

\/VVVV\A/VVVVVVVVVVVVVVVVVVVVVVVVV^XVVVVVVVVVVVVVVVVVVV\AA/VVVV\A/\AAAA/VVVV\AA/VVVV\AAAA/VV\A/VV\AAAA/\AA/VA 

Figure 1-8. Directory Filtering Method Specifying Date and Time. 

Filtering Classified Ads 


Since the classified system automatically costs and justifies ads every 
time they are filed, you cannot use an ad header for compiling directory 
filtering methods. An editorial type header allows you to file the filtering 
method without automatic costing and justification. In the example in 
Figure 1-9, the Raycomp Ad Header is used. However, you may find it 
more convenient to design a header specifically for use with directory 
filtering. 


The directory filtering method in Figure 1-9 selects ads which will stop 
running within the next four days, including today. 


FORM 9/25/81 

_ Auth WHITNEY 

Depth _ 


9: 59 


Width 


Section 


_ Proofs _ Expire Date 

Entered 9/23/81 Output _ Loc . 


Ad Type R Bask FILTER _ Desk 

Ad Id class filter Account _ 

1st Run Date _ Run Dates _ 

Edition 
Phone _ 

Remarks Selects ads which stop running in next four days. 
select stop'date >= today and stop'date < today + 4 
sort by author descending 

Figure 1-9. Directory Filtering Method for Classified Ads. 


Directory Filtering in Other Files 

As mentioned previously, directory filtering functions on any list for any 
file. Figure 1-10, below, illustrates a filtering method for user profiles. 
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FORM 9/24/81 12:54 

Changed by WHITNEY on 9/22/81 at 13:01:21 
Created by WHITNEY on 9/24/81 at 12:54 
Status E, 2 lines, 60 chars 

Story user filter Topic _ Keyword _ 

Basket FILTER _ Desk _ Author WHITNEY 

STYL _ Output _ (_) Template _ Private? R 

Pub Date _ Page _ Expires _ At _ 

Destination _ When Filmed? _ Send @ 0: 00 

Selects users who haven't signed off in the last three weeks _ 

select logoff'date < today - 21 

VVVVNAAAi\/VVVVVVVVVVV\A/VV\AAAAAAAAAAA/VVVV\A/VVNAAAAAAAAAAA/VVVV^A/VVVVVVVVVVVVVV\iVVVVVVVVVVVVVVVVVVVVV' 

Figure 1-10. Sample Filter for User Profiles. 


This directory filtering method contains a select statement which will 
select only those users who have not signed off in the last three weeks. 
Since the user file is a key-sequenced file, users are sorted alphabetically 
by default. 
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Template Takes for 
Directory Filtering Methods 

Directory filtering methods can be made more general through the use 
of template takes and are especially useful for listing files other than the 
take header file. 

Figure 1-11 illustrates a method that filters by access\evel and 
assign\evel. These criteria may be used in listing the user file, the 
basket file or the desk file since the structures for each of the three files 
contain these two fields. 


Story levels 


Basket FILTER 

STYL _ 

Pub Date 


Topic 

Desk 


FORM 

Keyword _ 

Author WHITNEY 


9/24/81 12:54 


Output 


(. 


Page 


_) Template T Private? _ 

Expires _ At _ 


Destination _ When Filmed? _ Send @ 0: 00 

Selects users, baskets or desks above the specified levels 

! Enter ACCESS LEVEL and ASSIGN LEVEL 

select access'level >= ^4^ AND assign'level > = M 


Figure 1-11. Index Filtering Template Take. 



The user follows these steps to customize the method take: 

1. Edit filtering method take “levels” with Icmdi FIFeI so that the header is 
hidden. 


2. Itabi once and enter the desired Access Level. The cursor will automat¬ 
ically move to the second field. Enter the desired Assign Level. 


3. Enter Icmdi 0 (the method take is filed automatically) and fill in the 
prompt with a list name (for users, baskets or desks) and the name of 
the filtering method take (and a key if you like): 


List Name user levels Path _ Proof _ Filter by levels 

Key__ 
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Only users will be listed who have Access Levels which are equal to or 
greater than 4 and Assign Levels at or above 6. The list could also be of 
“baskets” or “desks.” You may test for only the Access or the Assign 
Level by specifying the alternate value as zero (0) in the method take. 
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Section 2 

Use of Directory Filtering 

Directory filtering is enabled from any directory or index prompt. When 
specified in the directory prompt it filters only the current directory. 


Ritering a Directory 

To filter a directory, complete the directory prompt fields in the normal 
fashion, and enter the name of the filtering method in the “Filter by” field. 

Path _ Key _ List Name _ 

Proof _ Lines _ Filter by _ 

When the directory prompt is completed and the directory is called the 
message “Selecting/Sorting” may be displayed on the status line of the 

VDT. 

The command to redisplay the directory prompt ( IcmdI I~1 foil picks up 
all the information from the previous directory prompt including the 
directory filtering method. 

Note: The above prompt, including the filtering method, may be prefilled 
in a user-defined directory method accessed with IcmdI □ Q] 
through fcMDl □ Q2. 

Filtering an Index 

Directory filtering can also be specified in the index prompt ( IcmdI [x]). 

List Name _ Path _ Proof _ Filter by _ 

Key _ 

To filter an index, complete the index prompt fields in the normal 
fashion, and enter the name of the filtering method in the “Filter by” field. 

When the index prompt is completed and the index is called the 
message “Selecting/Sorting” may be displayed on the status line of the 
VDT. 

The command to redisplay the index prompt ( Icmdi □ 0) picks up all 
the information from the previous index prompt including the filtering 
method. 


Directory Status Messages 

The message “nn items rejected” is displayed whenever 50 or more 
items have been rejected since the last item was displayed. 

If the filtering method specifies a sort, the first message displayed is 
“Selecting/Sorting,” followed every 3 seconds by “nn items selected so far” 
or “nn items rejected”, whichever is appropriate. 
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When the directory is displayed, the system indicates whether it is filtered, 
sorted, interrupted, or only a partial listing with the appropriate message: 

filtered The directory is filtered, but not sorted. 

sorted The directory is a complete, sorted directory, and not o ne 

that was interrupted early by the user pressing |cmd| or 
because no space remained for items to sort. 
partial The directory is filtered and sorted, but there was not room 

in memory to sort additional items. _ 

interrupted The user interrupted item selection by pressing the |cmd| 
key. 

Interrupting Directory Filtering 

If you press fcMDl while items are being selected for sorting, the 
selection of items ceases and the items found up to that point are sorted 
and displayed. Normal selection/rejection will cease only when another 
command is completed. 

Ritering Methods Specified by List Names 

It is possible to specify a filtering method in a list definition. When this is 
done, using the list name also enables the filtering method. 

Note: There is no way to suppress the filtering of a directory when a 
filtering method has been specified for the list with lgen. The 
normal filtering method for the list may be overridden, however, by 
entering a different method in the directory prompt. 
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Appendix A 

Error Messages 

Error messages appear only when the directory filtering enabling 
command is given. Consequently, it is a good idea when writing a filtering 
method to end by trying to enable it rather than going on to some other 
task or specifically filing it. 

If a filtering method contains more than one error, the first one 
encountered will cause the appropriate error message to be logged. 

“A quoted string was expected”—When an expression contains a Q-field 
with a type of string or ucase, the program expects to compare it 
with a quoted string. When the first character following the relational 
operator is not a quote, this message is logged. 

“Arithmetic not allowed on strings”—Arithmetic operations, (addition, 
subtraction, multiplication, and division) may not be performed on 
quoted alphanumeric strings. 

“Command must be one of select/reject/sort” This message 
appears if a command is not recognized (spelled wrong). 

“Edit codes don’t match: (Q-field), (Q-field)”—The two Q-fields indicated 
were used in the same expression, but the edit codes don’t match. 
For example, comparing a Q-field with one digit after the decimal point 
to a Q-field that has 2 digits after the decimal point will cause this 
message to be logged. 

“Field (Q-field) does not exist”—You have used an incorrect Q-field name 
in a select or reject statement. Recheck your entries. 

“Illegal character in filter criteria”—Only alphanumeric characters and 
relational operators are allowed. For example, this message will be 
logged if g is used to end a line. 

“Invalid date specified”—A date has been entered incorrectly (for 
example, an impossible date (14/1/81) or one with too many slashes 
(10/19/81/)). 

“Invalid number specified”—A number has been entered incorrectly (for 
example, it contains illegal characters, or has too many digits after the 
decimal point). 

“me can’t be used with field (Q-field)”—This keyword can only be used in 
conjunction with Q-fields that reference a user. For example, this 
message will appear if me is used in combination with last"date 
instead of last"text"user. 

“Missing closing quote”—Alphanumeric strings must be enclosed in 
quotes. You have omitted the closing quote. 

“Missing Q-field name”—You have entered a select or reject statement 
without supplying the name of the Q-field to be referenced. 

“Missing relational operator”—You have entered operands without 
entering a relational operator to indicate the relationship to be tested. 


A.1 









Appendix A: Error Messages 


Directory Filtering 


“now can’t be used with field (Q-field)”—A time keyword can only be used 
in conjunction with Q-fields that reference a time. For example, this 
message will appear if now is used in combination with last'date 
instead of last'time. 

“Q-fields aren’t of the same type: (Q-field), (Q-field)”—The two Q-fields 
indicated were used in the same expression, but the types don’t 
match. For example, comparing a 1-word integer with a 2-word 
integer in an expression would cause this message to be logged. 

“Selection criteria contain too many constants!”—The available space for 
storing constants has been exceeded (rare). 

“Selection criteria too complex!”—There is a limit of 60 elements per 
filtering method. An element is each occurrence of a Q-field, a 
constant, an arithmetic operator ( +, -, *, and /), and each occurrence 
of a relational operator (<, < = , =, > = , >, and <>). 

“select/reject’s must precede sort’s” —You have entered the sort 
statement before the select/reject statement. 

“String too long”—String constants being compared to string or ucase q- 
fields may not be longer than the Q-field. 

“today can’t be used with field (Q-field)”—A date keyword can only be 
used in conjunction with Q-fields that reference a date. For example, 
this message will appear if today is used in combination with 
last'time instead of last'date. 

“Too many select/reject statements”—A maximum of 10 select and 
reject statements is allowed for each filtering method. 
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SECTION A-1 

Hardware Overview 

The principles behind System/55 are not very complex. The s y st ® m 
employs multiple processors, multiple controllers, multiple data paths be¬ 
tween system modules and multiple power supplies in all system configu¬ 
rations. 

System/55 uses all the main processors to a greater or lesser extent 
depending on work load. At any time, one processor has enough excess 
capability to run jobs it might have to take over from a failed unit. 

Switching from a failed processor to an operational processor is accom¬ 
plished through a proprietary NonStop technique. 


Hardware Elements 

System/55 is organized around these basic elements: the processors, 
the dynabus™, the Operations and Service Processor (tns-ii systems 
only; tns-i systems use a diagnostic link), dual ported disk drives, dual 
ported i/o controllers, and the various peripheral controllers and devices. 
In addition, System/55 features a sophisticated wire interface and he 
Tandem expand Data Communications Network. Figure 1-1 illustrates the 
NonStop system architecture. 


DYNABUS 


DYNABUS 




STD NonStop Architecture 


NonStop II Architecture 


Figure A-1.1. NonStop Architecture 
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The Processor 

Each Tandem NonStop processor module contains a dynabus interface 
(described below), its own Input/Output channel, Instruction Processing 
Unit (ipu), main memory, Diagnostic Data Transceiver (ddt), and power 
supply. 


The processor’s Instruction Processing Unit is a microcoded processor 
employing stack architecture. 

In the tns-ii, the instruction set supports two addressing modes. The 
standard 16-bit addressing mode gives high-speed access in executing 
programs to 16 megabytes of physical memory. The extended 32-bit ad¬ 
dressing mode, used mainly by the operating system, allows access to the 
entire virtual memory space. 


The DYNABUS™ 

Tandem’s high-speed interprocessor bus structure is called dynabus. It 
provides two separate communication paths linking all processors in a 
system. Each processor module is connected to all other processor mod¬ 
ules by a redundant pair of high-speed interprocessor buses. The two 
buses are fully autonomous: each operates independently of, but simulta¬ 
neously with, the other. If one should fail, the other automatically handles 
the total load. 


A failed processor cannot dominate the dynabus, since, in order to 
seize the dynabus, an independent external bus controller must agree 
that a given processor has a right of access. 


Transmissions on the dynabus take place at 13 million characters per 
second, dynabus transfers are both logically and physically separate from 
all other Input/Output operations. 


Operations and Service Processor 

On tns-ii Systems, the Operations and Service Processor (osp) inde¬ 
pendently provides an operator interface to the system and supports diag¬ 
nostic capabilities for maintenance and service of the system. Its built-in 
modem for connecting to a remote terminal or another osp permits remote 
diagnostic and corrective operations. 

A diagnostic link is available on tns-i systems. 


Disk Drives 


System/55 requires paired sets of physically independent disk drives 
treated as a single volume, known as “mirrored volumes.” 


A minimum disk configuration consists of two 300 mb drives (one mir¬ 
rored volume) or four 80 mb drives (two mirrored volumes). 

Using mirrored volumes, the system simultaneously records data on two 
separate disk packs. During read operations, the system uses its ability to 
access data from either drive to reduce head movement and seek-time. 


If a failure occurs on one disk, all reads and writes are automatically 
made from the other. 


When the failed disk is replaced, the new disk is normally brought back 
on line to exactly mirror the safe volume without interrupting application 
updates and access of data. 
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Dual Ported I/O Controllers 


Each input/output channel of a processor can communicate with a 
maximum of 256 input/output devices (32 controllers with up to eight units 
per controller). All i/o transfers between a processor and its attached i/o 
devices are handled on that processor’s private i/o channel. All i/o is Direct 
Memory Access (dma —devices transferring data simultaneously with 
bursts from one device interleaved with bursts from others). In tns-i, the 
i/o transfer rate may be as high as 4 mb per second. In tns-ii, the i/o 
transfer rate may be as high as 5 mb per second. 


The dual ported i/o device controllers are each connected to two i/o 
channels which are in turn connected to two independent processing units. 


A dual port controller is attached to separate i/o channels through 
physically separate interface circuits so that no interface chip can simulta¬ 
neously cause failure of both ports. 


Logically only one of the two ports of an i/o controller is active. The other 
is used only in the event of a path failure to the primary port. 


Fault Tolerant Transaction Modules 


The Fault Tolerant Transaction Module (ftm) provides a totally redun¬ 
dant high-speed buffered interface for Coyote I, qb and hb terminals 
attached to a Tandem Non-Stop II computer (TNS-II). The ftm is config¬ 
ured with a pair of high-speed asynchronous controllers (ftm.5) which are 
connected to the terminals through an Intelligent Patch Panel (or, optional¬ 
ly, through the Universal Patch Panel). 


Extended Transaction Module 


The Extended Transaction Module (xtm) provides a high-speed buff¬ 
ered interface for Coyote Terminals attached to a Tandem Non-Stop I 
computer (tns-i). The xtm is dual ported, and switches between i/o chan¬ 
nels in the event of a processor failure. A single xtm handles up to 16 
terminals. A single Tandem i/o slot is required for each xtm. 


Device Names 


The physical input/output devices on the system are identified with 
Device names assigned at system generation time. The names are pre¬ 
ceded by a dollar sign «$». The first character of a device name must be a 
letter, it can be followed by up to six numbers or letters in any combination. 
Each device name must be unique. 


For example, the disk drives on your system might be called «$system» 
and «$data»; a tape drive might be called «$tape»; a line printer might be 
called «$lp»; a typesetter might be called «$apsi», and xtms, ftms, or 
vcus might be called «$ai , $A2, $A3, and so on. 

In addition to a device name, since all input/output operations on the 
system are directed to a file, each device must have a unique file name. 


For devices with a single line, the file name will be the same as the 
device. For example, device «$tape» will have a file name «$tape». 


For devices with multiple input/output lines, each line must have a 
unique name. The most common example is an ftm, xtm, or vcu. The 
files associated with each line of an ftm, xtm, or vcu which is connected 
to an individual terminal are identified by name in the following format: 
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«$dn.#txx» (for et/960 terminals) or «$dn.#lxx» and «$dn.#rxx» (for 
Coyote terminals). 

Where: $dn is the device name 

«t» designates a vcu controlling an et/960 
«l» identifies the left side of a Coyote terminal 
«r» identifies the right side of a Coyote terminal 
«xx» is the terminal/line number on the ftm, xtm, or vcu 

For example, $a2.#ti o, $ai .#lo3, $ai ,#ro3. 


Wire Interface 

Two types of wire interfacing are available. 

Universal Communication Interface Adapter 

The Universal Communication Interface Adapter (ucia) provides a high 
speed buffered interface to synchronous and asynchronous devices. The 
ucia supports up to 16 lines, ten dedicated for asynchronous rs -232 at 
speeds up to 2,400 baud, two for synchronous or asynchronous RS-232 at 
speeds up to 9600 baud, and four for asynchronous rs-422 at speeds up 
to 19,200 baud. Each line is individually programmable for speed, charac¬ 
ter size, and parity. The ucia is dual ported, attaching to two Tandem i/o 
channels. Channel switching is dynamic, requiring no manual intervention. 

Transaction Processor Module 


Each Transaction Processor Module provides 14 asynchronous and 2 
synchronous channels for wire input at 100 to 19.2 « baud. 

These units are always installed in pairs; the system detects failure of 
any wire circuit and activates the alternate circuit with minimal loss of data. 


All wire services are supported at their respective speeds. Each 
System/55 processor can accommodate high- and low-speed wires for the 
entire system, giving the system virtually unlimited wire-handling capabili¬ 
ty- 


EXPAND Network 


The Tandem expand Data Communications Network allows SI I to sup¬ 
port all System/55 installations and also facilitates communication be¬ 
tween remote sites of a newspaper. Information can be communicated 
instantaneously over a telephone line connecting the System/55 installa¬ 
tions. The System/55 at a newspaper can be linked to the SI I System/55 in 
Sacramento, California, for software support. Extensive security measures 
ensure data base integrity. 


In the same way that Sll can be connected with a newspaper’s system, 
remote sites employing a network link can communicate with one another. 
System/55 architecture allows the nodes of the network—for example, a 
newspaper’s metropolitan headquarters in California, its suburban satellite 
plant, and its bureaus in Washington, London, Moscow, and Tokyo—to 
operate as one system. 
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SECTION A-2 

Software Overview 


System/55 software is comprised of three components: the Operating 
System which contains the programs which run the physical devices on 
the system; Application Programs which make possible the various func¬ 
tions which users may access from the vdt and operate the Editorial and 
Advertising systems; and Utility Programs which users initiate to perform 
specific tasks as required. 

The information required to run the software is stored on disk. In order 
for a program to run, it must be copied from the disk to the cpu. A program 
which has been copied into the cpu and is dynamically executing is known 
as a process. A process is a program that is running. 


Process Names 


Every process that is running in the system has a Process Identity 
Number (pid) which is assigned to it when the process is started. A typical 
process number might be oo,83. The first two digits of the pid indicate the 
cpu in which the process is running (here it is running in cpu 0) the second 
two digits identify the process. 


Processes may also be given names, for example SI I calls the System 
Overseers, which are described later in this section, $egod and $cgod. 
Processes must have numbers; but they need not be given names. 
Though we recommend that you use the names we have provided, you 
may give processes any name you wish. 


Process names must be preceded by a dollar sign. The name may 
contain a maximum of 4 characters. The first character must be a letter. 
The remaining 3 characters may be numbers or letters. Normally you will 
want to begin the names of processes on an Editorial system with «$e» 
and processes on a Advertising system with «$c». 


The processes running in the cpu which control i/o to and from your vdt 
also have names. The name of each vdt process begins with an alphabet¬ 
ic identifier. A typical vdt process name looks like this: $A506. 


The vdt also has a file name which is used when information is trans¬ 
mitted to it. A typical file name looks like this: $as.#lo6. Coyote terminals 
have two file names, one for the left side and one for the right side of the 
terminal. ET/960 terminals have one file name in the following format: 
$A5.#T06. 


Disk File Names 


Everything that is stored on disk—programs, text, headers, and so 
on—is contained in a file. Each file has a name by which it can be 
accessed, changed, and purged. 


File names are made of up of the volume (the physical disk on which the 
file is stored, for example, Ssystem), the subvolume (a location on the 
disk), and the file name. 
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The volume name is assigned at system generation time or when new 
disk packs are added to the system. The volume name is always preceded 
by a dollar sign «$». The first character of the name must be a letter, but 
the remaining 6 characters which are allowed may be letters or numbers. 


The subvolume name identifies a set of related files. As with the volume 
name, the first character of the name must be a letter, the remaining 7 
characters which are allowed can be numbers or letters. When the volume 
and subvolume name are written together, they must be separated by a 
period (for example, «$volume.subvol»). 


The disk file name identifies a particular disk file. The first character of 
the disk file name must be a letter, the remaining 7 characters which are 
allowed can be numbers or letters. When the subvolume and disk file 
name are written together, they must be separated by a period (for exam¬ 
ple, «$VOLUME.SUBVOL.DISK»). 


Here are some more typical disk file names: $system.sysdata.config, 
$SYSTEM.CLASS.HEADER, $DATA.EDITOR.TEXT. 


__ Basically, the data in System/55 is organized in the following fashion: 
Files are on disk, within the files are records, within the records are fields. 
When you display a form on your vdt you see a record from a file. When 
you display a list on your vdt you see selected fields from many records. 

Each field in a record is defined with Sll’s data definition language called 


The Super Process: $ZEUS 


The Super process, $zeus, oversees everything in the system. This 
process is responsible for maintaining all processes under its control (as 
defined in the configuration file records). 

$zeus is the ancestor of each process which it starts and is responsible 
for (looking at it from the other side, processes started by $zeus are its 
descendants). 


$zeus is notified by the operating system if a process stops. 


System Overseer Processes: $EGOD and $CGOD 

Each subsystem, for example Editorial and Advertising, has a System 
Overseer process, normally called $egod and $cgod which oversee the 
server and requestor processes under their control. $egod and $cgod are 
also the ancestors of their server processes. 


Requestor and Server Processes 

The System/55 processes are divided into two groups: Requestor pro¬ 
cesses, and Server processes. 


Requestor processes accept requests from vdt users and handle com¬ 
munications between server processes and between other requestor pro¬ 
cesses. 


Server processes service requests from the requestor process to per¬ 
form all basic system functions, justification, hyphenation, and spell check¬ 
ing for example. Each is an individual program which performs only one 
operation. 


A-2.2 


System Managers Manual 


Software Overview 


Data Files 

The files which are of primary concern to the System Manager are 
described briefly below. 


Process Configuration File 

The process configuration file controls the named processes which run 
your system, and the data files which these named processes use. It 
contains records which are read by the Super and System Overseer 
processes to start and maintain system processes. If a program is going to 
run on your system, it must have a record in the configuration file. 

Download Control File 


The download control file controls the programs which are necessary for 
the external devices (for example vdts) to run. The entries in the file 
determine which programs are downloaded to the devices. 

The programs are actually downloaded by the download processes. 
This process picks up the necessary files from disk and sends them to the 
proper device. 

Spooler Configuration File 


The spooler configuration file describes a set of programs which allow a 
process to send output to a physical device regardless of the state of the 
device. The spooling system consists of $spls, the spooling system su¬ 
pervisor, and $s, the spooling system collector. The spooling supervisor 
schedules jobs going out to the devices and handles the i/o to devices. If a 
device is off line, the spooler continues to collect data in the data file 
spl.data, transmitting it to the device when it becomes available at the 
rate at which the device can accept it. 


Each job which enters the spooling system has a location consisting of a 
#group and destination and written in the format «#group.destinati- 
on». The job location is the key to how the spooling supervisor will route 
jobs in the collector. When a job is output, it enters the spooling system 
where the job location is checked. If it matches the location of a device, the 
job is sent to the device (as the device becomes available). If the job 
location does not correspond to a device, the job is held in the data file 

(SPL.DATA). 


The spooling system is set up using the Tandem Utility spoolcom which 
allows locations to be mapped to devices. For example, #qume may 
indicate a qume printer, #aps may indicate an aps typesetter. 

Once the spooling system has been configured, the Sll utility scan 
allows you to monitor and control jobs. With it you many examine, delete, 
copy and hold jobs. 


User File 

The user file for each system contains information about the users in 
that system: passwords, defaults, authorities, Tandem user name, Tan¬ 
dem password, and all other user specific information. 

Header Files 


The header file (editorial) and cheader file (advertising) contain 
information about stories and ads on the systems but not the actual text of 
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the stories or ads: the name of the basket and desk it resides in, the list of 
users who have worked with the story or ad, pointers to current and 
previous versions and so on. 


Basket File 

The basket file for each system contains the information about each 
basket in that system. It contains the factors used in computing story 
expiration dates, and the sorting method to be used for items in the basket. 

Desk File 


The desk file for each system contains information about each desk in 
that system. It contains the sorting method to be used for items in the desk. 
It does not contain information affecting story expiration dates. 


Q Field File 

The Q-Field file contains the q field definitions for the fields in all records 
in all data files. 


List File 

The list file contains the information used to display and edit lists on the 
VDT. 

The lmsg file contains the actual list object code which is used to 
produce a directory on the screen. 


Form File 

The Form file contains the information used to display and edit forms. 

The fmsg file contains the actual form object code which is used to 
produce a form on the screen. 
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SECTION A-3 

Sll Command Interpreter 


Sll Command Interpreter is designed for improved security and user 
convenience. It allows you to execute commands and run programs. Ac¬ 
cess to Sll Command Interpreter is controlled by the «a"comint» Q-field in 
the User Profile. 


Running Sll Command Interpreter 


To enter Sll Command Interpreter press IcmpI []]. A semicolon prompt 
is displayed. If you have not previously logged you are automatically 
logged on as null.null. 

To log on as a specific Tandem user from Sll Command Interpreter, at 
the semicolon prompt, enter «logon» followed by the appropriate Tandem 
user name (for example, sii.super) and a comma, then press [ctrl! 0 
and enter the password. Pressing [ctrlI \ p \ prevents the password from 
being displayed on the screen. 


; logon s i i... .s up er, 


Figure A-3.1. Logging On from Sll Command Interpreter. 



Once you have logged-on, the system will remember your Tandem user 
name and its associated authorities. 

Pressing the |cmd| key while in Sll Command Interpreter aborts the 
currently execu ting command. If a command or process is not executing 
when the |cmd| key is pressed, the semicolon prompt is displayed. 

Editing the Sll Command Interpreter Command Line 

You m ay edit an Sll Command Interpreter command line using the 
IinsertI and IdeleteI keys at any time prior to executing the command by 
pressing ireturni . 

Should you find that you have made an error in command line syntax 
after you have pressed Ireturni . you may duplicate the command line, 
edit it and then re-execute it. To do so, position the cursor on the command 
line you wish to change and press ImoveI . (To duplicate the last command 
line entered you need only press the Imovei key.) The entire command line 
will be moved to the position of the last semicolon prompt on your screen. 
You m ay then make the necessary changes, and press 
Ireturni to execute the command. 

To exit Sll Command Interpreter and return to your basket and desk list, 
at the semicolon prompt, enter Ireturni or IctrU IyI. 



WHO 


The who command is useful if you forget your current defaults. When 
executed it displays your Tandem user defaults as well as other informa¬ 
tion relating to Sll Command Interpreter. 
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Enter «who» at the semicolon prompt to display the process name and 
primary and backup cpu of the Sll Command Interpreter, your default 
security level (Tandem user name), and your default volume, subvolume, 
and system. A typical who listing is illustrated in Figure A-3.2. 


; who 



VDT name: $A2.#T07 

VDT Process: $A207, Cl process: 

\SII. 02, 073 

Default volume: 

$SYSTEM.SYSTEM 


SII user: RICK, 

Tandem user: SII 

.SUPER (254,255) 


Figure A-3.2. Listing Provided by the who Command. 


If you use the network and the «system» command, you should use the 
«who» command frequently in order to avoid accidently running programs 
in the wrong system, unintentionally purging remote files, and so on. 

The «current system » field of the who listing is displayed only if you 
have previously used the system command to supply a new parameter. 

ACTIVATE 


The activate command allows you to return a process from the 
suspended state to the ready state. A process can be suspended in one of 
two ways: by executing the suspend command; or, a process can sus¬ 
pend itself or another process (by executing the suspend process proce¬ 
dure). 


Standard Tandem users (null.null, sii.class, sii.super, and super. s) 
can only activate their own suspended processes. In other words, you can 
only activate a process, or a descendant of a process, that you ran. 
Specifically, your current process access id must match the id of the 
creator of the process you are trying to activate, super.super can activate 
any process. 


When you execute the activate command, the designated process is 
placed in the queue of processes ready for execution and is executed 
according to its priority. 

To reactivate a particular process you must specify the process number 
or name. The syntax for the command is illustrated in Figure A-3.3. 

;activate 01,083 


Figure A-3.3. Activating a Process by Number. 


If the process is not running on the system to which you are logged on, 
you must specify the system on which the process is running. The syntax 
for the command is illustrated in Figure A-3.4, below. 


; activate, \sii.$eprg 


Figure A-3.4. Activating Process $eprg on System \sn. 


ALTPRI 


The altpri command allows you to change the execution priority of a 
process. Processes may be given priorities from 1 to 199. 
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To change the priority of a particular process, you must specify the 
process number or name, and the new priority at which it is to run. If the 
process is not running on the system to which you are logged on, you must 
specify the network node on which the process is running. The syntax for 
this command is illustrated in Figure A-3.5, below. 


;a 1tpri $ yrp r, 13 2 

Figure A-3.5. altpri Command to Change the Priority of Process $yrpr. 


sii.class, Sll.SUPER and super. s can alter the priority of only those 
processes and descendants of those processes they ran. This means that 
the current user’s process access id must match the id of the creator of the 
process whose priority is to be altered, super.super can alter the priority 
of any process. 

Altering the priority of a process can have serious effects on your 
system's performance. Be certain that you give careful consideration to the 
possible effects before you alter the priority of a process. 

CREATE 


The create command allows you to define a new disk file. When you 
create a file using this command, it will have the default security which was 
established when you logged on. The default security can be changed 
from Tandem Command Interpreter with the default command, but it will 
not become effective until the next time you log on. Once it has been 
assigned, you can change file security with the fup secure command 
(see the Tandem tns-i or tns-ii Master Index). 


You may specify the number of pages the file is to have. To do so, enter 
a comma following the file name, then enter the number of pages (a file 
page is 2048 bytes; a file may have up to 16 extents). If no extent size is 
specified, «1» page is assumed. 


For example, if your default volume and subvolume is $system.- 
mysubvol and you wish to create a file named «myfile» with those 
defaults, at the semicolon prompt enter «create myfile» (illustrated in 
Figure A-3.6). 


;create myfile 

Figure A-3.6. Command to Create myfile on Default Volume and Subvolume. 

If you wish to create a file on another subvolume, you must specify the 
subvolume name for the file. For example, the command «create $sys- 
tem.yrsubvol.yrfile, 7» (illustrated in Figure A-3.7) creates $sys- 
tem.yrsubvol.yrfile with an extent size of «7». 


; create $ sy s tem. yr _subvo 1. yrf i 1 e7 

Figure A-3.7. Command to Create File yrfile on Specified Volume and Subvolume with Extent Size of 7. 


To create a file on another system on the network, the network node 
name must be included in the create command as illustrated in Figure 
A-3.8 on the following page. 
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; _ c _ reate \si i. $system. my s ub vo l. ne wfi 1 e 


Figure A-3.8. Creating a File on Another Node of the Network. 


DEBUG 

The debug command allows you to force a process into the debug state 
(see the Tandem tns-i or tns-ii Master Index). 

sii.class, sii. super, and super.s are allowed to debug only those 
processes and descendants of those processes which they ran. That 
means your process access id must match the id of the creator of the 
process you are trying to debug, sii.class, sii.super and super.s are not 
allowed to debug privileged processes, super.super can debug any pro¬ 
cess. 

When you execute the debug command, the specified process enters 
the debug state with the execution of its next instruction in the user code 
map. 


:debug $yrprg 


Figure A-3.9. Command to Debug Program $yrprg. 

The TERM Keyword 

The keyword «term» of the debug command specifies the home termi¬ 
nal for the process being debugged. Since the debug prompt always 
appears on the home terminal of the process being debugged, the term 
keyword allows you to specify the terminal where the debug prompt will be 
displayed (as illustrated in Figure A-3.10). The home terminal of the pro¬ 
cess being debugged is permanently altered by the term keyword. 

If the term keyword is omitted, SII Command Interpreter assumes the 
executing terminal is to be used. 


;debug Jyrprpg, term $a2. #L06 


Figure A-3.10. Command to Debug $yrprg on Terminal $A 206 . 

If the process you are debugging is running in a system on another node 

of the network, you must specify the system name (illustrated in Figure 
A-3.11). 


; debug \si i. y r p r 


figure a-3.11. Command to Debug $yrpr on System \sn. 


FILES 

The files command allows you to display the file names associated with 
one or more subvolumes. 


Enter «files» at the semicolon prompt to display the names of all files 
on your default volume and subvolume. Figure A-3.12, below, illustrates a 

tem^s^s'tem^ 3 default volume and subvolume (in this case $sys- 
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;files 

$SYSTEM.SYSTEM 

AOPR AOPRLOG AOPRLOGO APSDUMP ARMTRACE B 

UNLOAD UPDATE USERID USERIDAK VS VUP 

Figure A-3.12. Command to List all Files on Default Volume and Subvolume. 

To list all files on a particular volume and subvolume, enter the volume 
name followed by a period and the subvolume name. Figure 3-13, below, 
illustrates the command syntax and a partial listing for all files in $sys- 

TEM.SYSDATA. 


;files $system.sysdata 
$SYSTEM.SYSDATA 





AOPRGROUP 

CHARFLGS 

CHARS 

CHARSO 

CHARS1 

CHARS2 

CHARS 

CMON 

CMONO 

CMON1 

CONFIG 

CONFIGO 

RESPONSE 

STATDESC 

SUBDEV 

DUBMIT 

SUFFIX 

SYSDESC 

VCUCTRO 

VSTOP 

VUPINFO 

VUPINFOO 

XYZZ 



Figure A-3.13. Command to List all Files in Volume $system, Subvolume sysdata. 


If you wish to list files in another system on the network, you must 
specify the system name. For example, «files \sii.$system.yrfile» 
would display all files in volume $system, subvolume yrfile on the \sn 

SYSTEM. 


OBEY 

The obey command allows you to instruct the Sll Command Interpreter 
to execute a series of commands from a specified take. The take may 
contain any Sll Command Interpreter commands except another «obey 
take» command. 


Obey takes can be used to perform repetitious functions with a minimum 
of keyboarding. 


Creating an Obey Take 

To create an obey take, enter the commands you wish the take to 
execute just as if you were executing them from command interpreter. 

Executing an Obey Take 

You may abbreviate the obey command as the letter «o». To obey a 
take you have created, enter «o storyname» at the semicolon prompt. 

You may stop execution of an obey take at any time by pressing the IcmdI 
key. If you do so, the obey take stops executing and you are prompted for the 
next command. 


PAUSE 

Enter «pause» at the semicolon prompt. This causes the command 
interpreter to stop prompting for commands. A command interpreter in the 
pause state is not awakened to prompt for a command until the most 
recently run process is deleted or you press the Icmdi key. 

When the pause command is executed, the command interpreter waits 
for “descendant stopped” messages about the process last run. If a pro¬ 
cess number is specified, command interpreter will pause until the speci- 
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tied process stops. Note that the specified process gets “adopted” by 
command interpreter and the “stopped” message goes to command inter¬ 
preter not to the process that created the specified process. 

PPD 


The ppd command allows you to display process names and informa¬ 
tion associated with the processes currently entered in the process-pair 
directory. 

To get a listing of all processes in the process-pair directory, at the 
semicolon prompt, enter ppd and press [return]. Some of the entries 
which might be seen in a typical ppd listing are illustrated in Figure A-3.14. 

To obtain a ppd listing of only Editorial or only Classified processes, 
enter «ppd $e*» or «ppd $c*» to list all processes beginning with e and c 
respectively. 

Fields in the PPD Listing 

The entry in the name field is the name of the process. If the entry in this 
field is $zooo, this is the process started when the system is cold-started. 

The entry in the pidi field is the primary process number for this pro¬ 
cess. The two digits preceding the comma indicate the cpu in which the 
process is running; the remaining digits identify the process. For example, 
in Figure A-3.14, the entry «02,058» indicates that process 58 is runnina in 
cpu 2. a 



;ppd 

Name 

$Z000 

$CMON 

PIDI 

00,023 
00,024 

PID2 

01,026 
01,027 

Parent 

00,000 
$Z000 

Program file name 
$SYSTEM .SYS02 
$SYSTEM .SYSTEM 

.COMINT 

, CMON 

$EGOD 

$CGOD 

01,040 
01,042 

00,054 
00,043 

$ZEUS 

$ZEUS 

$SYSTEM 
$SYSTEM 

. SII 

. SII 

GOD 

GOD 

$A812 

$A811 

00,070 
02,058 


$ZEUS 

$ZEUS 

$SYSTEM 
$SYSTEM 

. SYSTEM 

.SYSTEM 

ECONTROL 

ECONTROL 


Figure A-3.14. Typical Entries in a ppd Listing. 


The entry in the pid2 field is the backup process number for this pro¬ 
cess. If there is no entry in this column, the process has no backup. 

The entry in the parent field is the name or number of the process 
responsible for initially creating this process. Note that the startup process 
($zooo) does not have an entry in this field. 

The entry in the program file name field is the name of the program 
file for this process. 


PURGE 

The purge command is used to delete a disk file. When a file is purged, 
its disk file name is deleted from the volume’s directory and any space 
previously allocated to that file is made available to other files. 

A file can be purged only if it is not currently in use (that is, it is not open, 
running, or being backed up) and the current user has purge access to the 

file or is logged on as super.super. A typical purge command is illustrat¬ 
ed in Figure A-3.15. 
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;purge myfile 

Figure A-3.15. Command to Purge File myfile. 

Sets of files can be purged in a single operation with the fup purge 
command (see the Tandem tns-i or tns-ii Master Index). 

RELOAD 

The reload command is used to load a processor module’s operating 
system image during an initial cold load from disk or after a failed module 
has been made operable. The reload takes place while the remainder of 
the system operates in a normal manner. 

Any super.* user can execute the reload command (see the Tandem 
tns-i or tns-ii Master Index). 

RENAME 

The rename command allows you to assign a new file name to an 
existing disk file. With the rename command you can change the subvol¬ 
ume name and or the disk file name but not the volume name. The volume 
name can only be changed by copying the file to another volume with the 
fup program (see the Tandem tns-i or tns-ii Master Index). 

To rename a file, at the semicolon prompt, enter «rename» followed by 
the current name of the file, a comma and the new name. Figure A-3.16 
illustrates typical rename command syntax. 


;rename ofilnair^nufi1nam 

Figure A-3.16. Typical rename Command Syntax. 


RUN/RUND 

The run command is used to run programs. The command also allows 
you to optionally specify the program’s input and output files, processor 
module, execution priority, number of data pages, and process name. Any 
program file you specify to run must reside in the system in which it is to 
run. 

Enter «run» at the semicolon prompt followed by the program name to 
start the process. Enter «rund» at the semicolon prompt followed by the 
program name to start the process and put it into debug state before it 
executes its first instruction. 

A series of options, as explained below, may be entered following the 
program name. Options must be enclosed in slashes and separated by 
commas as illustrated in Figure A-3.17. 


; run.myprog/IN$myfile J 0 UT$yrfile,NA^$mYpr ) CPy_ 0 J PRI 135 ,...MEM 

8 J.NOWA I: T,.TERM $ a3 02 / 


Figure A-3.17. run Command Syntax. 


The IN Option 

The in option allows you to specify the process’s input file. For example 
«in $myfile». If no file name is supplied the terminal from which the run 
command is executed is assumed. 
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The OUT Option 

The out option allows you to specify the process’s output file. For 
example «out $yrfile». If no file name is supplied, the terminal from 
which the run command is executed is assumed. 


The NAME Option 

The name option allows you to assign a name to the process. For example, 
«name $mypr». Giving the process a name allows you to find it in the ppd 
listing. If you omit this parameter, the process is given a number but not a 
name. 

The CPU Option 

The cpu option allows you to specify the processor in which the process 
is to run. If you do not specify a cpu number, the system will select a 
processor. 


The PRI Option 


The pri option allows you to specify the priority at which the process is 
to run. A priority from 1 to 199 may be specified. If you do not specify a 
priority, the system will select a suitable priority. If you specify a priority 
greater than the maximum, an error message is given. 

The MEM Option 


The mem option allows you to specify the maximum number of virtual 
data pages (from 1 to 64) which are to be allocated to the process. 

The NOWAIT Option 


The nowait option allows you to specify that the Sll Command Interpret¬ 
er prompt be returned once the process has started. 

If you do not specify the nowait option when the run command is 
given, the command interpreter waits for the new process to stop before 
prompting again. Press [cmd] to redisplay the semicolon prompt. The 
command interpreter will then continue to run while the other process is 
running. However, if the other process needs to use the home terminal it 
will be blocked. To return the command interpreter to its waiting state use 
the pause command. 


If you do specify the nowait option, the command interpreter redisplays 
the semicolon prompt as soon as the new process is started and has read 
its parameter message. The nowait option is typically used when starting 
up several programs with an obey take. 

The TERM Option 

The term option allows you to specify the home terminal for the pro¬ 
cess. If the term option is not used, the terminal from which the run 
command is executed is assumed. 


STATUS 

If you enter the status command with no parameters it displays the 
terminal ^ pr0CeSses which have the executing terminal as the home 

To dfsplay the status of a specific process, enter the process name or 
umber following the status command. For example, «status $egod». 
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To display the status of all processes running in a particular cpu, enter 
the cpu number following the status command. For example, «status i » 
or «status o». 


To display the status of all processes running in all cpus, enter an 
asterisk following the status command. For example, «status*». Por¬ 
tions of a typical status* listing are illustrated in Figure A-3.18. 


;status* 






PID 

Pri 

Name 

Home Term 

Program 

file name 


00,000 

201 


$OSP 

$SYSTEM 

.SYS02 

OSIMAGE 

00,001 

210 


$OSP 

$SYSTEM 

.SYS02 

OSIMAGE 

00,023 

199 

o 

o 

o 

N 

m 

$OSP 

$SYSTEM 

.SYS02 

,COMINT 

00,054 

164 

$EGOD 

$TERM4 

$SYSTEM 

. SII 

GOD 

00,082 

140 

$A310 

$TERM4 

$SYSTEM 

. SII 

ECONTROL 

00,083 

140 

$A307 

$TERM4 

$SYSTEM 

. SII 

ECONTROL 


Figure A-3.18. Typical Entries in status* Listing. 


The PROG Condition 

The prog condition allows you to display the status of processes having 
a particular program file. To use it, enter prog followed by the program file 
name. For example, «status*,prog sii.econtrol». 

The TERM Condition 

The term condition allows you to display the status of processes run¬ 
ning on a particular terminal. If you do not specify a terminal name, the 
executing terminal is assumed (the result is the same as if you had entered 
status with no parameters). For example, «status.,term $osp». 

If you specify both the prog and term conditions, only the status of 
processes satisfying both conditions is displayed. 

STOP 

The stop command allows you to stop a process which is currently 
running. At the semicolon prompt, enter «stop» followed by the name or 
number of the process you wish to stop. If the process is running on 
another system, you must enter the system name preceding the process 
name or number. The syntax of a typical stop command is illustrated in 
Figure A-3.19. 


;stop $a207 

Figure A-3.19. Command to Stop Process $A 207 . 

sii.class, sii. super and super. s are allowed to stop only those pro¬ 
cesses and descendants of those processes which they ran. Your process 
access id must match the id of the creator of the process you are trying to 
stop, super.super can stop any user process. 

SUSPEND 

The suspend command allows you to prevent a process from compet¬ 
ing for system resources. A suspended process cannot execute instruc- 
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tions until it is reactivated. A suspended process can be reactivated with 
the activate command. 


This command differs from stop since the process can resume execu¬ 
tion as though no interruption had occurred. 


The suspension does not take effect until the designated process be¬ 
comes ready to execute instructions. Therefore, any outstanding waits (as 
for i/o completion) are satisfied before the process is suspended. 

At the semicolon prompt, enter «suspend» followed by the name or 
number of the process you wish to suspend. The syntax of a typical 
suspend command is illustrated in Figure A-3.20. 


;suspend $mypr 

Figure A-3.20. Command to Suspend Process $mypr. 


sii.class, sii. super, and super. s are allowed to stop only those pro¬ 
cesses and descendants of those processes which they ran. That means 
that your process access id must match the id of the creator of the process 
you are trying to stop, super.super can stop any user process. 

SYSTEM 


To set the default system, at the semicolon prompt, enter « system» 
followed by the system name. If you enter the «system» command by 
itself, the local system is specified as the default. The local system is the 
system on which your command interpreter is running, not necessarily the 
system to which your terminal is physically connected. 


; system \s_ii 

Figure A-3.21. Command to Set Default System to \sn. 


TIME 

The time command allows you to display the current setting of the 
system’s date and time-of-day clock. At the semicolon prompt, enter 
«time» as illustrated in Figure A-3.22. 


; t ime 


Figure A-3.22. time Command. 

The time command applies only to the local system; you cannot obtain 
the time from a remote system unless you run a command interpreter on 
that system. 


VOLUME 

The volume command is used to change the current user’s default 
volume and subvolume names. 

At the semicolon prompt, enter «volume» followed by the new volume 
and/or subvolume name(s) to change the current default setting 

JSr; a r r" subvo,um * name ' en,er wo.* by 
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To change your default subvolume name, enter «volume» followed by 
the new volume name. 

To change both your default volume name and default subvolume name 
enter «volume» followed by the new volume and subvolume names. The 
command syntax for changing default volume and subvolume is illustrated 
in Figure A-3.23, below. 


; volume __$system, .sysdata 

Figure A-3.23. Typical volume Command Syntax. 
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SECTION A-4 

Defining Tandem Security 


This section covers the application of Tandem security to System/55 
and makes recommendations for its use. 

Tandem security is independent of any systems which may have been 
defined at your site. Satisfying the requirements of Tandem security in¬ 
volves two basic tasks: 


1. Defining Tandem user ids for each node of the network (if applicable), 
together with local and remote passwords; and 

2. Securing certain files that are critical to system operation. 

Tandem user ids may be used in the following ways to gain access to 
the system: 

• When a System/55 user is signed on to an et/960 or Coyote editing 
terminal running under a System/55 vdt control process («econtrol» 
for editorial, «ccontrol» for advertising), the default Tandem user 
specified in his User Profile (the last group/user he signed-on as) is 
checked for some functions accessing files (discussed later). 


• While signed-on under a System/55 vdt control process, a user with 
Command Interpreter authority may execute the Sll Command Interpret¬ 
er with icmdi Q] («;» prompt) or, with a list of accessible processes, start 
a process with ICMDl fsl. Either of those commands will automatically log 
the user on as his default Tandem user. The Sll Command Interpreter 
supports the logon command, allowing a user to change his default 
Tandem user. 


• Through the Sll Command Interpreter («;» prompt), a user may execute 
the Tandem Command Interpreter «comint» («:» prompt) and logon as 
his assigned Tandem user: 

fCMDl fTl ... 

;comint 

: logon tandem.username 


The only reason for executing the Tandem Command Interpreter is to add 
and delete Tandem Users and to change their passwords. All other 
COMINT functions are supported by the Sll Command Interpreter. 

• To logon directly as a Tandem user to a non-editing console terminal. 


Defining Tandem User IDs 

In the sense that System/55 uses them, Tandem User ids can be 
thought of as being “accounts"—(group id), (user id). Tandem “Users” do 
not represent individual persons (although they can for data processing 
purposes), but rather account numbers used by a number of individual Sll 
users to gain access to system files and processes. A user's Tandem 
account number is recorded in his user record as information-only in the 
Q-fields tandem"group and tandem'user. These fields may be included 
in User Profile and User Defaults forms and in lists of users. 
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System/55 uses the four standard classes of Tandem system user. 
They are significant in their (group ids) and (user ids) as follows: 

(group id) = 255, (user id) = 255 —Super ID. May perform any operation in the system. 

Can update or purge any file. 

(group id) = 255, (user id) = 254 —System Operator. May perform standard* and 

hardware oriented operations. 

(group id) = 254, (user id) = 255 —Group Manager. May perform standard operations* 

and define new Tandem users. Has access to all 
files belonging to his group, except files restricted to 
Super id. 

(group id) = 000, (user id) = 000 —Standard (null) User. May only perform standard 

operations.* 

* Standard operations include creating and purging disk files, running programs, display¬ 
ing system status, and so on. In System/55 these abilities apply only to users with Com¬ 
mand Interpreter authority. This is not a recommended authority for standard users. 

There may be only one super id and only the super id can define new 
groups; this user is therefore the “group manager” of all groups. Although 
up to 256 groups of 256 users each are possible, we will generally prefer to 
narrow the accounts to those few that will have real meaning in our 
publishing system. (If a separate data processing system is configured, a 
broader range of groups and users may be defined.) Wherever possible 
we will let the more specific authorities in the User Profile control the range 
of a user’s activity in the system. 


User Definition 


When a new System/55 is presented to the customer during the pre-in¬ 
stallation staging, a degree of security will already have been defined by 
Sll. At that time your Sll Site Manager will advise you in defining any new 
Tandem users you may require. 

Two Tandem users are required for system operations: «super.super» 
(255,255) and «super.sched» (255,253). These users must not be 
changed. 

Tandem users are defined with the comint (Tandem Command Inter¬ 
preter [«:» prompt], not Sll Command Interpreter) adduser command in 
which both names and numbers are supplied for group and user. The 
syntax is: 


: ADDUSER (group name), (user name) , (group ID), (user ID) 

Execute comint through the Sll Command Interpreter ( Icmdi Q]). The 
following are recommendations: 

• Super ID 

There may be only one Super ID per system (“system” is defined here 
as being a node of the network, not a locally-configured system). This 
user must be named «super.super» (255.255). 

Use of super.super should be limited to an absolute minimum of 2 
persons and a probable maximum of 4 persons at any site. The mini¬ 
mum of 2 persons covers illness and vacations; the maximum is in 
recognition of the great power and responsibility this user has. The 
super.super user is immune to all system security and thorough sys¬ 
tem knowledge is imperative for its use. Under the tutelage of the 
system manager and other super.super user(s) at the site and by 
attending various courses offered by Tandem Computers, a group man¬ 
ager class of user can progress to the level of super.super user. 
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In a network, a node’s super.super user has no special capabilities on 
a remote system, nor do any other users. All users are limited by the file 
security effect on any particular system (see “File Security” later in this 
section). 


• System Operator 

There should be one System Operator user per system. By convention 
this user is named super.s (255,254). This user will normally be used 
by maintenance personnel and those individuals who monitor the hard¬ 
ware of the system. 


• Group Manager 

The group manager class of user is signified by a group id which is less 
than 255,and a user id which is equal to 255, the same user id as the 
super.super user. A group manager must be added to the system by 
the super.super user. A group manager has the capability of adding 
new users to his group, but generally this capability is inapplicable to a 
publishing system (it is not useful to have additional members of the 
group). Therefore, the super.super user should be responsible for 
adding all new Tandem users. 


This class of user is a means of exercising unique control over 
System/55 users with Command Interpreter authority, who otherwise 
are fairly unrestricted in their activity. The way it is employed depends 
on the distribution of knowledge and responsibilities at the site. For 
example, the knowledge (background, training) and aptitude required to 
write styl procedures, to specify wire routing procedures, to define 
advertising operations, to maintain the vdt character matrix library to 
maintain devices and fonts, to schedule programs and to write specifica¬ 
tions for reports may not all be found in a single individual, or a single 
function (job description) being filled by more than one individual. It is 
also possible that the system manager (super.super) would avoid 
delegating all of these responsibilities to a single function (role) being 
performed by one or more persons. Any or all of the following groups 
might be added to delegate and restrict responsibilities: 


Group.User 

Group,User 


Names 

Numeric IDs 

Permitted Function 

SCHED.SUPER 

101,255 

Defining User Access to Programs, 

Program Scheduling and Message Groups 

WIRE.SUPER 

102,255 

Defining Wire Routing 

CLASS.SUPER 

103,255 

Defining Advertising Operations 

DICT.SUPER 

104,255 

Dictionary Maintenance 

FONT.SUPER 

105,255 

Defining Devices and Fonts 
and Maintaining the vdt Matrix Library 

STYL.SUPER 

106,255 

Compiling styl Procedures 


Each of the above users is restricted to a set of functions typical of a 
newspaper publishing system. Any individual, given knowledge of the 
appropriate password, may logon as any one of these users prior to 
performing the related function(s). Later in this section, under “File Securi¬ 
ty,” we’ll discover how we can give data files to these Tandem users and 
then secure them. 


Note that Form Generation and List Generation are not among the func¬ 
tions restricted to these groups. Those processes are more effectively 
controlled by levels in the User Profile. It is not required that any of the 
above areas be restricted in this way. Similar objectives could be accom¬ 
plished by more severely limiting Command Interpreter authority and 
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granting users access to programs only with the program scheduler 
«schedset». The limitation in doing so is that only program execution is 
prevented, files are not protected (access with the Index command is more 
difficult to prevent), and capable users are unnecessarily restricted. This 
method, as will be seen more clearly later in this section, provides a nice 
balance between slamming the door shut on information and leaving it 
wide open, neither of which extreme is desireable in a publishing system. 

• Standard User 

All other users in a system are Standard Users known as «null.null» 

(000,000). These are normal editorial and advertising users who do not 

have Command Interpreter authority. However, they may have Utility 

Authority and a list of Available Processes. 

A System/55 user, when first created, is a null.null Tandem user. He 
will remain as such until he is shown how to change his account by 
logging-on as a higher level Tandem user with the appropriate password. 
Users may be graduated through the hierarchy of Tandem users by being 
given additional training, new responsibilities, and knowledge of a new 
Tandem user name and its password. Only users with Command Interpret¬ 
er authority may become other than null users. 

When a System/55 user signs-on under either the econtrol (editorial) 
or ccontrol (advertising) vdt control process, he or she is automatically 
signed-on as a Tandem user under the default account number in the User 
Profile. This Tandem user status is checked by any user commands 
reading or writing to files other than those containing takes, baskets, and 
desks; these are special files which are generally available within the 
bounds of implicit or explicit authorities in the User Profile. 

Passwords 

All Tandem user names should be protected with passwords. Pass¬ 
words are assigned with the comint Password command (see Guardian 
Operating System Programming Manual, “Security System”). 

Define a password on an interactive Sll editing terminal by entering 
ICTRLl (pj between the Password command and the password itself: 

: password [CTRLl \p} (new password) 

This prevents the password from being displayed on the screen. Pass¬ 
words are limited to the ascii character set and control characters recog¬ 
nized on console terminals. If other (typesetting) characters are used, the 
password will not be usable on console terminals. 

Enter a password in the comint Logon command on an interactive Sll 
editing terminal by preceding it with ictrli (p[. Consult your Sll System 
Engineer for instructions on how to logon to console terminals. 

It is recommended that passwords be changed at least once a 

week. The frequency of change depends on the judgement of the system 
manager. In order that password security may be properly coordinated, it 
is further recommended that the responsibility for changing passwords lie 
only with the system manager or other super.super user delegated as 
“password editor." Periodically this user should change all of the pass¬ 
words (including remote passwords, where appropriate) and inform the 
affected users of the changes orally. It is important that passwords never 
be written down, for that invalidates their purpose. 
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Whenever an employee with access to other than a null.null user re¬ 
signs or is dismissed, it is a useful precaution to immediately change the 
passwords of all user names of which he or she may have knowledge. 

Network remote passwords should be coordinated with Sll (for as long 
as you choose to participate in the Sll Network) and with all other nodes of 
the network with which you desire interaction. 


File Security 

Once all the Tandem user accounts have been defined, it is necessary 
to complete the picture by “giving” certain important data files to specific 
user accounts and then “securing” them. The super.super user may give 
a user the ability to read a file, to write to it (change it), execute it (if a 
program) or purge it, both locally (within the node of the network) and by 
similar users in other nodes of the network. 


Relating Tandem File Security to System/55 

There are four types of access for a file: 


read, 

write, 

execute (run), and 
purge. 


Through fup (File Utility Program; see Tandem Operating Manual), for 
each of these four types of access a file may be secured on any one of 
seven levels, each of which is represented by a letter or symbol. 

Local: 

a = any local user 

g = any local member of the same group, the owner or super.super 
o = owner or super.super only 
- = (hyphen) local super.super only 


Network: 

n = any network user, local or remote 

c = community members only (any user on any system whose group id 
matches that of a file’s owner 

u = any user on any system, local or remote whose numeric user id 
( not user name) matches that of the file’s owner 


Only local security is bypassed for the super.super user. A file may 
have only one owner; the file’s “owner” is the creator of the file or a user id 
to which the file is given with the fup Give command. 


Both the local and network levels of security are meaningful in 
System/55. A major feature of System/55 enables Sll to support its cus¬ 
tomers through the Guardian/Expand Network. Many customers, in turn, 
support remote sites as nodes of the network. Together, all nodes—Sll, 
each customer’s central node (the newspaper) and remote nodes (bu¬ 
reaus) established for individual customers—comprise the Sll Network. 
Explicit cooperation is required between the respective super.super user 
of the nodes of the network in establishing remote passwords. 


In reading the examples and the levels of security suggested for specific 
files in the balance of this section, be aware of how the vdt control 
processes— «econtrol» for editorial and «ccontrol» for advertising— 
examine the security levels: 


A-4.5 




Defining Tandem Security 


System Manager’s Manual 


• The program and data files accessed by all user commands—except for 
the Index, Form, and Start Process commands—are opened by the vdt 
control process as user super.super. That ensures that standard users 
may not be inhibited by the Tandem security system from performing 
their tasks, regardless of a file's ownership. 


• The Index command ( [cmd! 0) examines the read access level any 
data file (program files cannot be indexed) a user attempts to index. If 
this level is other than «n», standard users are prevented from obtaining 
indexes of the data in the file. 


• All three levels of the Form command ( [cmd! [f]) examine the execute 
access level of a data file, not the write level. This lends a great deal of 
freedom to the securing of data files. Data files are not programs and 
cannot be executed; the Tandem security system does not examine the 
execute access level for a data file, since it is inapplicable. The Form 
commands do examine this level, however, without subverting Tandem 
security. 

If the write level is low («n») and the execute level is high («c», «u» or 
«-»), most users can be prevented from accessing records in the file 
with the Form commands; records may still be accessed with any pro¬ 
gram which updates them, provided the user has execute access to that 
program file. 


If the write level is high and the execute level is low for a data file, data 
records can be easily accessed with the Form commands, but access 


by other means requires a much higher level Tandem user. 

Note that these factors are not true of the header files, user files, desk 
and basket files; these are special System/55 files to which access is 
controlled in the User Profile. 


Note: A program in a user’s List of Accessible Processes does not 
exempt that program and the user from execute access checks. It 
simply allows the user to execute the program without Command 
Interpreter authority. 


Examples of the security levels applying both locally (at each node) and 
within the network follow. The headings have the following meanings: 
R = read, w = write, e = execute, and p = purge— «rwep». 


Examples: 

R W E P 

N C N C 


Discussion 

This is the security with which Sll normally supplies files to 
customers. Any network user may read; only community 
members may write; any network user may execute; only 
community members may purge. Writing and purging are the 
most critical capabilities. All files, as supplied, are initially 
owned by super.super users within the network, but only 
those with whom remote passwords (allow access/request 
access) have been established. Initially, access is only be¬ 
tween Sll and the customer site. 
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CAUTION 

So that SI I may give you continuing support 
through the SI I Network, please continue to use 
the network security— «n», «c», and «u»—for all 
System/55 program and data files supplied by Sll, 
except for Purge access which should be changed 
to «-» (local super.super only) whenever owner¬ 
ship of a file is given to a user other than su¬ 
per.super. If local read, write, and execute levels 
are assigned to files, your Sll System Engineer will 
be unable to render assistance through the net¬ 
work. 


R W E 

C C C 


c u u 



Discussion 

Anyone in the network community may read, write or 
execute, but only the local super.super may purge. This 
would make sense only for files which do not need to be 
available to standard users, even for listing. 

Anyone in the network community may read, but only a 
network user with the same id as that of the owner may write 
or execute and only the local super.super may purge. If a 
program file owner’s id is «250,255», the only users who 
may write or execute are the owner, a network user id of 
«250,255» or the local super.super (255,255). A remote 
super.super would not be able to execute this program. If 
these access levels were assigned to a data file, only users 
with the same id as that of the file’s owner would be able to 
change data in the file, with or without the Form command; 
only the community members could read the file, including 
using the data in a report. 


cue- Any community user may read or execute, but only users 
with the same id as that of the owner may write to the file, 
and only the local super.super may purge it. This is a useful 
variation on the above combination of access levels. 


u u u - Only network users with the same id as that of the owner 
may access the file, and only the local super.super may 
purge it. This is the most restrictive form of network security, 
whether it be for a data file or a program file. It could possibly 
apply to the font files, with the exception of the font header 
file (see next example). 


n u u 



Any network user may read this file, but only users with the 
same id as that of the owner may write to it or execute it, and 
only the local super.super may purge it. This too, is fairly 
restrictive. It would be useful to secure the font header file 
(«system. s/fe. fonts », where site is your site’s designator) 
in this way. Useful indexes of font names, descriptions, and 
so on, would therefore be available to all users. 
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R w e p Discussion 

n n n n No!! This is the equivalent of no security at all. 

Files created locally by your own programming personnel may use the 
local security levels «a», «g», and «o». 


File Names 


Data files and program files have names in the form: 

[\(system). ] $(volume name), (subvolume name), (disk file name) 

The node of the network («\») is shown here only because it is part of a 
complete network file name. Locally, you will specify file names only with 
that portion of the name beginning with the dollar sign ($), and that is the 
way they are shown throughout the following discussion. 

For the purposes of this discussion, the volume name is unimportant, 
since it will vary from site to site with the number of disk drives and data 
organization. To properly represent complete file names, however, all 
volumes are referred to as «$system». 

In many instances, subvolume name will be a designator unique to your 
site: «$system.sjmn.name». In these cases, the subvolume name is 
represented as «s/'fe»: «$SYSTEM.s/'fe.NAME». 

Lists of files in your system and detailed information about them can be 
obtained with the fup Files and Info commands. The Subvols command is 
also useful for listing the subvolume names on a designated volume. 


“Giving” File Ownership 

In order to delegate responsibility and, subsequently, to restrict access 
within the system (see “Securing Files,” below), it is useful for the su¬ 
per.super user to “give” the ownership of certain data files (but not 
program files) to other users. This is the equivalent of saying “Here, this is 
your responsibility.” 

The greatest number of files must be retained under the ownership of 
super.super. Those files which we will be discussing here are some of 
the data files required by you and your personnel for controlling and 
customizing your system. 

The names of most data files whose ownership you might wish to 
change may be found in an index of your configuration file. You may also 
list files in which you are interested with the fup Files command. The fup 
Info command may be used to list files with security information, along with 
other details about them. In the “Owner” column of the list, «-l» means 
super.super; all other owners are indicated with their numeric ids. This list 
also displays the files’ access levels. 


The super.super user “giving” file ownership is invited to consult the 
Sll System Engineer for his specific recommendations relative to your 
organization. Since no two publishers organize their personnel in precisely 
the same way, it is difficult to make clear-cut recommendations here. What 
we will do instead is illustrate aspects of a theoretical security system to 
make you aware of the possibilities. 


Recall the group managers suggested earlier in this section: 

f^rmin Near I I ~ 


Group.User 
Names 

SCHED.SUPER 
WIRE.SUPER 


Group,User 
Numeric IDs 

101.255 

102.255 


Permitted Function 

Defining User Access to Programs, 

Program Scheduling and Message Groups 
Defining Wire Routing 
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Group.User 

Names 


CLASS.SUPER 
DICT.SUPER 
FONT.SUPER 


STYL.SUPER 


Group,User 
Numeric IDs 

103.255 

104.255 

105.255 

106.255 


Permitted Function 

Defining Advertising Operations 
Dictionary Maintenance 
Defining Devices and Fonts 
and Maintaining the vdt Matrix Library 
Compiling styl Procedures 


To each of these Tandem users we, as super.super, will give the data 
files relating to their functions. This is done with the fup Give command: 


-give $system. site. wtime, 102,255 


These users represent specialized areas of system knowledge and/or 
responsibility. The files listed below enable them to perform within bounds 
of their functional roles. The lists of files are not necessarily complete; new 
files to support new features are constantly being added. Moreover, file 
names may be different at various sites and certainly will differ, where 
appropriate, between systems at the same site. 


Note that only data files are given to these users, not program files. 
Programs must remain under the ownership of the super.super user. A 
program may be executed by a user only if that user has access to the 
data files opened by the program. 


Owner 

SCHED.SUPER 


Data File Name 

$SYSTEM.SCHED.PROGRAMS 
$SYSTEM.SCHED.GRPACC 
SSYSTEM.SCHED.GRPACC0 
SSYSTEM.SCHED.GRPACC1 
SSYSTEM.SCHED. USERS 
SSYSTEM.SCHED. USERS0 
SSYSTEM.SCHED. USERS1 
$SYSTEM.SCHED.TIMES 
SSYSTEM.SCHED.TIMES0 
$SYSTEM.SCHED.TIMES1 
SSYSTEM.s/te.DEVDESC 
SSYSTEM.s/te.EFILE 
SSYSTEM.s/fe.CFILE 


File Description 

Available programs/descriptions 
Group to program relationships 
Alternate key file 
Alternate key file 

User to group/program relationships 

Alternate key file 

Alternate key file 

Program execution times 

Alternate key file 

Alternate key file 

Physical vdt group definitions 

Editorial message group definitions 

Advertising Message group definitions 


. . --» y.WU H ... 

inis user, with program «schedset», has the responsibility for defining the Lists of Available 
Processes for all users and for scheduling the automatic execution of programs. This user is 
responsible also for securing terminals by assigning them to groups, and for defining message 
groups to be used for message and transfer alter transmissions within the system. Note that 
most of these files are the same for all configured systems. Each system may have a separate 
message group file, as shown here, or they may all share the same file. 


Owner Data File Name 

WIRE.SUPER $SYSTEM.s/fe. WTIME 

SSYSTEM.s/fe.WTIMEO 
$S Y STEM.site . WH E AD 
$SYSTEM.s/te.WHEAD0 
$SYSTEM.s/te.WKEYWD 
SSYSTEM.s/fe.WKEYWDO 
$SYSTEM.s/te.WTABCODE 
$SYSTEM.s/'te.WSTATUS 
This user is the newspaper’s expert on wire 
editors in the definition of wire baskets and 
groups (sched.super actually defines the user 


File Description 

Routing based on days and times 
Alternate key file 

Routing based on wire service headers 
Alternate key file 
Routing based on keywords 
Alternate key file 

Coding replacements for tabular takes 
Data on last take received for each wire 
handling and routing. He cooperates with wire 
desks, routing specifications and transfer alert 
s belonging to message groups). 


Owner Data File Name 

CLASS.SUPER $SYSTEM.s/te.CLASSC 

$SYSTEM.s/te.ADTYPEC 
$SYSTEM.s/'te.CMASTER 
$S YSTEM .site . CM ASTE R0 
$SYSTEM.s/te.CREDIT 
$SYSTEM.s/te.PUBGROUP 
$S Y STEM .s/te. RATES 
$S Y STEM.site .TRANS 

Responsible for defining all functional details 


File Description 

Advertising control records 

Ad type definition records 

Customer information records 

Alternate key file 

Bad credit records 

Publication group/edition definitions 

Rate tables 

Info-only transaction statistics 
of the advertising system. 
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Owner Data File Name File Description 

DICT.SUPER $SYSTEM.DICT.MASTER Dictionary 

This user is responsible for maintaining the complete dictionary used for hyphenation and 
Spellbinder. No other user, except for super.super, may add, edit, or delete words. It is 
recommended that several persons be designated as “dictionary editors” and that all proposed 
changes be routed to them. 


Owner Data File Name 

FONT.SUPER $SYSTEM.s/te.DEVTABLE 

$SYSTEM.s/te. FONTS 
$S Y STEM.site . FONTSO 
$SYSTEM.s/te.INDEX 
$SYSTEM.s/te.lNDEXO 
$SYSTEM.s/fe.lNDEX1 
$SYSTEM.s/te. WIDTH 
$SY STEM.site . FWIDTHS 
$SYSTEM.s/fe.CHARS 
$SYSTEM.s/fe.MATXREF 
$SYSTEM.s/te.LOCALMAT 
$SYSTEM.s/Ye.XYZZ 
$SYSTEM.s/fe.GRAPHICS 
Responsible for all typesetting devices, fonts 


File Description 

Typesetting device records 
Font header records 
Alternate key file 
Index to recode and width tables 
Alternate key file 
Alternate key file 
Font width and recode data 
Film width/device location records 
Global library of vdt character matrices 
Index to site’s local character set 
Local matrices stored by tcu 
xyzz values for all internal codes 
Printer graphic strings for all internal codes 
keyboard tables and vdt matrix library. 


Owner Data File Name 

STYL.SUPER SSYSTEM.STYL.STYLDESC 1 

$SYSTEM.STYL. VARIABLE 2 
$SYSTEM.STYL.CONSTANT 2 
$SYSTEM.STYL.OPERANDS 2 
$SYSTEM.STYL.KEYWORDS 2 
$SYSTEM.STYL.STYLC0DE 3 
SSYSTEM.STYL.STYLINDX 3 
$SYSTEM.STYL.STYLSPCE 3 
^sed for an index of styl procedures available 


File Description 

styl name/description records 
Names of styl variables 
Names of styl constants 
Names of styl operands 
Names of styl keywords 
Compiled styl procedures 
Index to styl procedures 
styl space remaining 
to all users. 


2 Contain all of the reserved words used in the writing of styl procedures. Only “keywords” is not 
available for lists. 

3 For system use only. 


Any System/55 user writing styl procedures may logon as this user. Other users may not add 
or change procedures. 


Securing Files 

Once the ownership of files has been established, it is necessary to 
secure them within the network. Here we will concern ourselves with only 
those data files “given” in the discussion above. 

In terms of a d ata file, Read access applies to the ability to read the data 
into a list ( |cmd| [xj or, in the case of the dictionary, Icmdi 0) or a report 
(rgen), or to access it by executing a program which opens the file; 
without read access to the file, a user may not view the data under any 
circumstances. Write access applies to the ability to change (add, edit, 
delete) data in the file through execution of a program. Execute access for 
data files applie s only to the ability to add, edit, or copy data with the 
various level s of 1£ md] Purge access applies to the deleting of records 
in a file with |cmd| □ [kJ (Purge Record from File) or to deleting an entire 
file; normally, this access must be reserved for the local super.super 
user. 


A user’s ability to run a program depends on the program’s execution 
access and on how the program opens the data file(s)—for reading only 
(e.g., «busy») or for reading and writing (most programs). If a program 
opens a file as read-only and the user has read access to the file, the user 
may execute that program. If a program opens a file for reading/writing, the 
user must have access to the file on both levels in order to run the 
program. 
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All security violations encountered while a user is running under a vdt 
control process (econtrol or ccontrol) are reported on the status line 
as “Outside your jurisdiction.” Violations encountered when a user at¬ 
tempts to run a program interactively are reported as: 

OPEN FAILED FOR (file name) ERROR 48 

and normal execution of the program is halted (it is abended). 

In assigning security levels to data files, it is necessary to give careful 
thought on an individual file basis to who may view (i.e., read) and who 
may change (write, execute) data. Lists available on vdts and in hardcopy 
form must be considered, and so must reports compiled with the Report 
Generator «rgen». A user may not obtain a report or list which opens a file 
to which he does not have access. 

We may now proceed in securing our files. This is done with the fup 
Secure command: 


-secure $system.sched.programs, ’mi--’ 


OwnerSCHED.SUPER 

File Name 

Security 

R W E P 

Comments 

SSYSTEM.SCHED.PROGRAMS 

NU - ■ 

Any user may read; only owner’s id may write; only 

SSYSTEM.SCHED.GROUPS 

NU - • 

super.super may execute (vdt forms are not permit¬ 
ted for updating records) or purge. 

Same. 

SSYSTEM.SCHED.GRPACC 

NU ■ ■ 

Same. 

SSYSTEM.SCHED.GRPACCO 

NU • • 

Same. 

SSYSTEM.SCHED.GRPACC1 

NU - ■ 

Same. 

SSYSTEM.SCHED.USERS 

NU - ■ 

Same. 

SSYSTEM.SCHED.USERSO 

NU • ■ 

Same. 

SSYSTEM.SCHED.USERS1 

NU ■ • 

Same. 

SSYSTEM.SCHED.TIMES 

NU ■ ■ 

Same. 

SSYSTEM.SCHED.TIMESO 

NU - ■ 

Same. 

SSYSTEM.SCHED.TIMES1 

NU - - 

Same. 

SSYSTEM.s/fe.DEVDESC 

NUU- 

Any user may read; only owner’s id may write or 

SSYSTEM.s/'fe.EFILE 

NUU - 

execute (vdt forms are normal method for updating 
records); only super.super may purge. 

Same. 

SSYSTEM.s/'fe.CFILE 

NUU- 

Same. 

Owner:WIRE.SUPER 

File Name 

Security 

R W E P 

Comments 

SSYSTEM.s/fe.WTIME 

NUU ■ 

Any user may read; only owner’s id may write or 

SSYSTEM.s/fe.WTIMEO 

NUU - 

execute (vdt forms are normal method for updating 
records); only super.super may purge. 

Same. 

SSYSTEM.s/'fe.WHEAD 

NUU ■ 

Same. 

SSYSTEM.s/fe.WHEADO 

NUU • 

Same. 

SSYSTEM.s/fe.WKEYWDO 

NUU- 

Same. 

SSYSTEM.s/fe.WTABCODE 

NUU ■ 

Same. 

SSYSTEM.s/fe.WSTATUS 

N - - - 

Information-only file. Any user may read, but only 


super.super may write, execute or purge. 


Owner:CLASS.SUPER 

Security 


File Name 

R W E P 

Comments 

SSYSTEM.s/'fe.CLASSC 

NUU ■ 

Any user may read; only owner’s id may write or 
execute (vdt forms are normal method for updating 
records); only super.super may purge. 

SSYSTEM.s/fe.CMASTER 

NUN • 

Same. 

SSYSTEM.s/fe.CREDIT 

NUU- 

Any user may read; only owner’s id may write or 
execute (vdt forms are normal for updating records); 
only super.super may purge. 
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File Name 

$SYSTEM.s/te.PUBGROUP 
$SYSTEM.s/te. RATES 
$SYSTEM.s/te.TRANS 


r w e p Comments 

N U U - Same. 

N U U - Same. 

N - - - Information only file. Any user may read, but only 
super.super may write, execute or purge. 



Owner:DICT.MASTER 

File Name 

SSYSTEM.s/fe.CLASSC 

Security 

R W E P 

N U - - 

Comments 

Any user may read; only owner’s id may write; only 
super.super may execute (vdt forms are not permit¬ 
ted for updating records) or purge. 

Owner:FONT.SUPER 

Security 


File Name 

R W E P 

Comments 

SSYSTEM.s/fe.DEVTABLE 

NU - ■ 

Only owner’s id may read or write; only super.super 
may execute (vdt forms are not permitted for updating 
records) or purge. 

SSYSTEM.s/fe.FONTSO 

NUU- 

Same. 

$SYSTEM.s/'fe. INDEX 

NU ■ ■ 

Only owner’s id may read or write; only super.super 
may execute (vdt forms are not permitted for updating 
records) or purge. 

SSYSTEM.s/'fe.INDEXO 

NU - - 

Same. 

SSYSTEM.s/'fe.INDEXI 

NU - ■ 

Same. 

SSYSTEM.s/te. WIDTH 

NU - ■ 

Same. 

SSYSTEM.s/fe.FWIDTH 

NU - - 

Same. 

$SYSTEM.s/'fe.CHARS 

NU ■ ■ 

Same. 

SSYSTEM.s/fe.MATXREF 

NU - ■ 

Same. 

SSYSTEM.s/fe.LOCALMAT 

NU - • 

Same. 

SSYSTEM.s/fe.XYZZ 

NU - ■ 

Same. 

$SYSTEM.s/fe.GRAPHICS 

N U - - 

Same. 


Owner:STYL.SUPER 

Security 


File Name 

R W E P 

Comments 

SSYSTEM.STYL.STYLDESC 

N U U - 

Any user may read; only owner’s id may write or 
execute (vdt forms are normal method for updating 
records*); only super.super may purge. 

SSYSTEM.STYL. VARIABLE 

U - - - 

Information-only to writer of styl procedures. Only 
owner’s id may read; only super.super may write, 
execute, or purge. 

SSYSTEM.STYL.CONSTANT 

U - - - 

Same. 

SSYSTEM.STYL.OPERANDS 

U - - - 

Same. 

SSYSTEM.STYL.KEYWORDS 

u - • • 

Same. 

SSYSTEM.STYL.STYLCODE 

uu - ■ 

Only owner’s id may read or write; only super.super 
may execute (vdt forms are not permitted for updating 
records) or purge. 

SSYSTEM.STYL.STYLINDX 

uu - - 

Same. 

SSYSTEM.STYL.STYLSPCE 

u u - - 

Same. 


A styl description is given in a statement in the procedure itself and is loaded when the procedure is 
compiled. An existing description may be changed by editing its record in this file, or preferably, by 
changing it in the source take and recompiling the procedure; or both, if you do not wish to recompile 
the procedure. 

Observe that for some data files vdt forms are the normal method of 
adding, changing, and deleting information in records; but for other files 
this is not permitted since a specific application program is required to 
validate the data. The other type of data file of note is one in which the data 
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is updated by a process (running program); these files are always 
read-only to users. 

In the security recommendations above, only super.super has purge 
acces s to all files. This means that other users may not delete records with 
|cmd| Q [kJ (does not apply to record deletion with an application program 
such as fmod). You may wish to relax this restriction for certain files (e.g., 
wire routing files) by giving them a purge access of «o» (local owner or 
SUPER.SUPER only). 

There may be other files in your system that are worthy of security 
considerations. Please discuss these with your Sll System Engineer. 
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SECTION A-5 

Physical VDT Security 

System/55 provides two methods for physically securing the use of vdts 
and user names: 


1. by assigning vdts and users to groups representing their physical 
locations and/or functions, and 

1. by allowing users to secure their user names to physical vdts when 
they sign-off. 


Defining VDT Groups 

VDTs are grouped by completing a record like the one illustrated in 
Figure A-5.1 for every terminal in the system. There should be such a form 
in your system. The normal form and list names are «terminals»; the 
data file is «$SYSTEM.s/fe.DEVDESC» and the structure is "Device'descw. 


VDT name $B2.T11 

Group Contract Ad 

Description Mary Green's desk 



Figure A-5.1. Terminal Description Record. 


Three fields are available in this record: 


vdt name —This is the name of the vdt and also the key to its physical 
connection in the system. The name is comprised of two parts, sepa¬ 
rated from each other with a period. The first part identifies the Video 
Control Unit (vcu), or Terminal Control Unit (tcu) to which the vdt is 
connected—in this case, «$B2» —and the second part identifies the 
slot in the vcu or tcu —#tii —into which its communications or 
controller board is plugged. The complete name— «$b2.#tii» —is 
used to identify the terminal in transactions between the vcu and the 
host computer, allowing the vdt to interact with its process (each 
terminal has its own process in the host computer). This particular 
process name would appear in compressed form in the configuration 
file as «$B 2 i i »—vcu B2, terminal # 11 . These conventions permit 
terminal names to be used throughout the network. 


group —The group (up to 12 characters) to which the vdt and the users 
who may sign-on to it belong. Groups are as you define them here 
and in User Profiles, in which each system user may be assigned to a 
group (not be be confused with message groups, which are not 
reflected in User Profiles). See additional discussion below under 
“Assigning Terminals and Users to Groups.” 


description— The description (up to 30 characters) of the vdt’s use, 
which may be the name of the terminal’s user or the function normally 
performed on that terminal. This description is displayed on the status 
line following the name of the system when the vdt is signed-off or in 
an idle state. 


The describing of vdts in this record is a means of personalizing the 
system (including making users more comfortable with it) and of exerting 
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control; it is not required for system operation. If you do not create a record 
for the vdt or if you create a record but do not give a description, the vdt’s 
name (in this case $b2.#ti i) will be displayed as the description. 


Assigning Terminals and Users to Groups 

The relationship between the group named in the Terminal Description 
Record and the group named in the User Profile is one of simple corre¬ 
spondence: 

• If all vdts are assigned to groups and no group is specified in a user’s 
profile, that user may sign-on to any vdt. This capability is intended for 
certain production personnel who may be called on for assistance in 
non-production areas. 

The terminal description file is common to the entire site, regardless of 
how many systems have been configured. The only reason for defining 
VDT/user groups is to restrict the use of vdts in specific locations. If this is 
not desired, the «group» field should be left blank in both the Terminal 
Description Records and in User Profiles. 


In the simplest of situations, imagine that we have two VDT/user 
groups— “editorial” and “classified.” All vdts located in the newsroom 
and other editorial offices are assigned to the editorial group; those vdts 
located in the classified department are assigned to the classified group. 
Likewise, editorial and classified users are assigned to these respective 
groups in their respective User Profiles. The result is that an editorial user 
may not sign-on to the editorial system on a classified vdt and classified 
users are not permitted to sign-on to their system in the newsroom. 


Carrying this control further, the classified and editorial areas may be 
broken down into more specific groups. In the classified department, for 
instance, the groups «solicitor», «credit» and «censor» would limit the 
use of vdt in an area to users assigned to that area. Similarly, in editorial, 
the groups «city», «national», «sports», «leisure», and so on, would 
prevent editors and reporters from using vdts outside their assigned ar¬ 
eas. If the site has word processing users, the group «wp» could prevent 
them from using terminals in classified or in the newsroom. This can be an 
effective way of preventing employees from using each other’s desks. 

«group» can also be applied to a single user-terminal relationship. A 
managing editor whom we will call “John Smith” has a vdt in a private 
office. John’s vdt is assigned to group «john smith»; in John’s User 
Profile, and in no other, the group «john smith» is specified. Only John 
Smith may sign-on to the vdt in his office. John himself may not sign-on to 
any other terminal, at least not as “John Smith.” 


Signing-off at a Secured Location 

Users may secure their user profiles at specific vdts by signing-off with 
the second level sign-off command— Icmdi Q [z]. This method prevents 
the user name from being used on any other vdt in the system. It does not, 
however, prevent other users from signing-on to the terminal under their 
own user names. It is presumed that a vdt signed-off with Icmdi Q [z] is in 
a locked office; otherwise this practice has little meaning. This form of 
security is totally independent of vdts and users secured by the group 
method. 
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Returning to the example of John Smith, whose terminal is secured by 
virtue of his own proprietary group, it would be redundant for him to 
sign-of f in th is way. In his case, the group accomplishes the same objec¬ 
tive as Icmdi (TJ m and provides the additional benefit of preventing other 
user names from being used at his vdt. As far as the vdt is concerned, 
there is no reason for him to lock his office unless he has been careless in 
letting other persons know his password. 
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SECTION A-6 


PROOF Process 


PROOF is a process that handles proof requests from system users, 
directing these requests to a selected proofing device, such as a line 
printer, word processing printer, or other printing device. When mapgen 
formats and textgen tables are defined, and their names are entered in 
the Proof Key Record (see “The Proof Key Record”), proofing to non-ASCii 
printers is possible, (mapgen and textgen are documented in the Editorial 
Manager’s Manual, S55-010). 

Requests to proof are serialized, handled one at a time, and sent by 
the system overseer to the various proof processes running on the sys¬ 
tem. 


Figure A-6.1 shows a sample proof. Your proof header may contain 
fewer or different fields than this example. 


<1 


PROOF of Story '#5366' Requested by MIKE ($A002) on 3/29/82 15:36:25 

Copied from story ’#5168’ Entered 3/29/82 at 15:14 Expires 3/31/82 at 8:00 (OVERRIDE) Originator: AP-WIRE Author: MIKE 
'eader/text changed by MIKE (Text changed by MIKE at line 39) on 3/29/82 at 15:36:07 


lasket: MIKE WORK Level 0 from basket NATIONAL by MIKE on 3/29/82 at 15:32:53 

Desk: WIRE Level 1 

Topic: PHILADELPHIA Keyword: TRAINS COLLI Pub. Date: 3/30/82 Part: A Page: 1 Edition: MET1 
43 actual lines, 1,583 characters 

Default STYL: NEWS Device: APS ( ) Just Status: E 

Spell Status: * (Last spelled on 3/29/82 at 15:20:26 with 18 errors) 


Guide: AM-TrainsCollide 


LN# TEXT 


03-29 0250 


L 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 
17 


(A2)AM-Trains Collide,250(ql) 

26 Injured In Train Collision Near Philly(ep) 
(Al) BRISTOL, Pa. (AP) -- A stalled Boston- 
to-Philadelphia passenger train was 
rammed by a locomotive that had been 
sent to help tow it Monday, and 26 people 
were injured, none seriously, authorities 
said.(ep) 

Three of the injured were admitted to Bucks 
County hospitals and were in satisfactory or 
stable condition, while others were treated 
for cuts and bruises and released, (ep) 

Amtrak spokeswoman Debbie Marciniak 
said the engineer of the six-car train report- 


Figure A-6.1. A Sample Proof Header and Proof. 
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Running PROOF 


The proof process is run from the configuration file. Figure A-6.2 shows 
a sample proof configuration file record. 


To access the configuration file record for the proof process, type IcmdI 
0 and complete the prompt as follows: 

List Name conf ig _ Path jm Hardcopy _ 

Key $eprf * ____ 

Type IcmdI [f] to display the first item listed. 


System E Record type 0_ Process type 3_ Record #21 

Process Name $EPRF _ 

Primary CPU 0_ Alternate CPU 0_ Available CPUs 0_ 

Priority 90_ Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class _ Reference name _ 

Home Terminal ___ Rund 

Input File Name 

Output File Name _ 

Parameter String system, spooler name, justified spec. 
dev width 


Figure A-6.2. Configuration File Record for proof. 


system designates the system on which the process is operating; for 
example, «e» for Editorial or «c» for Classified. 


process name— The name ($eprf) of the proof process. 
priority— The priority at which the proof process is to run. 


The PROOF Parameter String 

The entries in the parameter string field of the proof configuration 
file record control the appearance of the printed proof. These parameters 
are listed and explained below. 


(system) is the system identifier, such as «e» for Editorial or «c» for 
Classified. It is required. 


(spooler name) defaults to «$s» if not specified. 


(justified spec) is the justification status indicator proof uses to determine 
whether to print input text only or output/input text, proof checks the 
indicator in the justification^status field of the story header against 
the indicator entered here. 


1. If a story is not justified, and the justification status matches the 
indicator in the parameter string, proof prints only input text. 

2. If the indicator in the parameter string is an asterisk «*», proof 
prints output text only if the take is currently justified. 


3. The letter «e» in the string causes proof to print output text and 
input text regardless of the justification status. 

Proofs from printers which use a mapgen format and textgen table dis¬ 
play text as specified in the format and table. 


(dev width) specifies the maximum column width of the proofing device. 
proof uses the configured device width for the width of the proof. 
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However, the printed width of all processes, in particular $s, is consid¬ 
ered to be 132 columns. So, if the width is not specified, proof 
will use 132 columns. Thus, stories proofed to $s.versi will 
always be whichever width is less, 132 columns or the config¬ 
ured width. 

Examples of Startup Parameters 

In the examples below, the required commas in the parameter string are 
separated by spaces for easier reading. When entering parameters in the 
system, you need not separate the commas with spaces. 

To always print input and output text, up to a width of 100 columns: 

Parameter string e, , e, 100 _ 

To print only input and output text if justified, up to a width of 132 
columns: 

Parameter string e, , *, __ 

The Proof Key Record 

The Proof Key Record specifies the device and form name(s) to be used 
when a user executes a proof command. The entry in the proof field of 
the user’s User Defaults determines which Proof Key Record is to be used. 
For example, if a user has printer entered in the proof field of her user 
defaults, all her proof requests will be directed to the device specified in 
the Proof Key Record with printer entered in the key field. In addition, if 
the specified device is a non-ASCii printer, this record indicates the map- 
gen format and textgen table to be used for conversion. 

To list or define Proof Key Records, type fcMDl [x] and complete the 
prompt as follows: 

List Name proof keys Path _ Hardcopy 

Key _ 

A sample Proof Key Record is illustrated in Figure A-6.3 below. The 
fields in the form are explained immediately following the illustration. 


Key Device 

Name 

Access 

MAPGEN Format 

TEXTGEN Table 

Wrap 

No Conversion _ 



Default FGEN form names: 




Figure A-6.3. The proof key Record. 


key —A name specified in the the proof field of the User Defaults. 

device name —This may be a physical device or a name by which the 
user may find the proof in the spooler perusal process scan to review 
it before actually printing it. 

access —Access level. 

mapgen Format—If this record applies to a non-AScn printer, enter the 
name of the mapgen format to be used here. 

textgen Table—If this record applies to a non-ASCii printer, enter the 
name of the textgen table to be used here. 

wrap —The permissible length of a line before wrapping takes place. 
Generally, this field is left blank (off) for line by line conversion. 
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no conversion— This field is used mainly for testing. If set on, by entering 
«x» textgen conversion will not be performed. This field must be off 
(blank) for non-ASCii printers. 


default fgen form names —The name of the form(s), designed with 
fgen, to use for printing the header. If a single form cannot contain all 
desired fields, you may design as many as five forms, each taking up 
where its predecessor left off, to make up your proof header form. 

List the forms here, in order, proof requests each successive form 
name from vputget ($pvpt, $evpt, etc.) to output the header so that 
it appears to the user as a single form, proof performs some format¬ 
ting on the resultant string received from $pvpt so that fields which 
are not info only may be present. These form fields are useful be¬ 
cause they are fixed length. Info only fields have trailing blanks 
stripped. 


Proofing a Story 

The user may choose either of two commands to proof a story or ad: 

1 • Icmdj □ [pJ is used if a user wants a take returned to the vdt screen for 
editing after it has been proofed. When the user enters this command 
while a take is displayed, the take is forwarded to the proofing device, 
then redisplayed on the screen. 


2. Icmdj 0 is used to proof while a take is displayed or from a directory to 
forward a take to the proofing device. 


User Options for Proof Format 


Each user’s User Defaults form contains eight user-changeable fields 
that govern certain aspects of proofing for that user. The options apply only 
to printers which do not use a mapgen format or textgen table. They are 
ignored if the proof field of the User Defaults contains the name of a Proof 
Key Record for a printer using mapgen and textgen. 


Figure A-6.4 illustrates these fields. 


Proof 


Input text only? 
Suppress banner? 
Double spacing? 

Output text only? _ Output commands? 

Suppress line numbers? 

Triple? _ 


Figure A-6.4. The Proof Fields in the User Defaults Form. 


proof —The entry in this field must match the entry in the key field of a 
Proof Key Record which defines the proof location for the user. 

INPUT TEXT ONLY?— Enter «x» to have only input text printed. Default is 
both input and output text. 


output text only? —Enter «x» to have only output text printed. 


output commands?— Enter «x» 
output text. 


to have output commands printed with 


suppress banner?— Enter «x» to specify the omission of the line begin¬ 
ning “Proof of story ...” The first line of the form will be the first line of 
the proof. 
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suppress line numbers? —Enter «x» to instruct proof not to print line 
numbers, column labels, and the line of dashes separating the header 
from the text. 

double spacing? —Enter «x» to specify double spacing of the printed 
proof. The default is single spacing. 

triple? —Enter «x» to specify triple spacing of the printed proof. 

Representation of VDT Attributes on Proofs 

The input text column of a proof (displayed only on proofs from printers 
which do not use a mapgen format or textgen table) contains ten sym¬ 
bols—(A1), <A2), (A3), and so on through (AO)—to represent user vdt 
attributes 1 through 10 on the et/960 vdt. 

On the Coyote vdt the 16 symbols (A1) through (A16) represent attri¬ 
butes 1 through 16. Whenever the attribute in the input text changes, the 
symbol for the new attribute is inserted in the input side of the proof. 

The symbols for the Coyote vdt and their meanings are shown in Table 
A-6.1, below. The attribute symbols are consistent with the keyboard 
layout and the styl typesetting language. Note that these are the normal 
displays; you may change the displays for any and all attributes. 


Table A-6.1 

Coyote VDT Display of STYL Attributes 

STYL Attribute 

Normal 

Number 

Display 

(A1) 

Normal 

(A2) 

Bold 

(A3) 

Strike-through 

(A4) 

Italic 

(A5) 

Dotted underscore 

(A6) 

Bold italic 

(A7) 

Bold dotted underscore 

(A8) 

Bold strike-through 

(A9) 

Italic strike-through 

(AO) 

Italic dotted underscore 

(All) 

Bold italic dotted underscore 

(A12) 

Bold italic strike-through 

(A13) 

Wavy underscore 

(A14) 

Bold wavy underscore 

(A15) 

Italic wavy underscore 

(A16) 

Bold italic wavy underscore 


The symbols for the et/960 vdt and their meanings are shown in Table 
A-6.2, on the following page. 
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Table A-6.2 

ET/960 VDT Display of STYL Attributes 

STYL Attribute 
Number 

How Displayed 

<A1> 

Normal 

(A2) 

Bright 

<A3> 

Strike-through 

<A4> 

Solid-underscore 

<A5> 

Broken-underscore 

<A6> 

Bright/Solid-underscore 

<A7> 

Bright/Broken-underscore 

(A8) 

Bright/Strike-through 

(A9) 

Strike-through/Solid Underscore 

(AO) 

Strike-through/Broken-underscore 



The proof process assumes a default of normal lightface for the first 
character of text. This means that an attribute symbol will appear before 
any text only if the attribute of the first character is not normal lightface. 

You may define attribute meanings in styl procedures to suit your own 
applications. 
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SECTION A-7 

AOPR 


AOPR is a process which receives operator messages and writes them 
to the console and a log file. Messages are held in the log file until it 
becomes full, when the oldest messages are over written by new mes¬ 
sages. Normally, aopr is started at system cold-start or warm-start from 
an obey file. 



Figure A-7.1. The aopr Process. 

AOPR Run Command 

The aopr run command may be entered in the following format from the 
Sll Command Interpreter or from an obey file. 

aopr/ name $AOPR, out (outfile name), nowait/(logical system 
name) 


name (processes name)—The name given the process, must be $aopr. 

out (out file name)—The name of the file where $aopr messages will be 
logged. 


nowait—Specifies that the Command Interpreter prompt be returned with¬ 
out waiting for the $aopr process to complete. 


(logical system name) 

gathered (for example «siie»). 


i ne system tor wmcn operator messages 


A typical aopr run command might be entered as illustrated below: 

;aopr/ name $aopr,out $osp,nowait/siie 
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Listing AOPR Messages 

The aopr log file has three paths which may be used when listing 
messages on your vdt: 

1. dt, the date on which the message was logged; 


2. tx: the first 10 characters in the message, and 

3. fr: the network node, cpu number, and process id number. 

To list all aopr messages currently held in the file, enter IcmdI [x] and 
complete the prompt by entering «aopr log» in the list name field and 
pressing ireturni . 


List Name aopr log Path _ Proof _ Filter by 

key 


A portion of the resulting list is illustrated in Figure A-7.2 below. The list 
begins with the oldest message currently held in the file. 


fr 


AOPR log file 
Msg Date Time 
15 02DEC 12:00 
15 02DEC 12:00 
02DEC 12:04 
02DEC 12:13 
02DEC 12:13 


From _ Text 

001,00,003 LOG TERMINAL LDEV # 0003, DISK LOGGING ON 
001,00,003 LOG TERMINAL LDEV # 0012, DISK LOGGING ON 
001,00,026 $DNC; I/O failed $A5.#T00: error 301 
001,00,011 NO RESPONSE FROM $C0 
001,00,011 GOOD SESSION ON $C0 


12/08/82 9:26 


Figure A-7.2. aopr Log Listing; No Path or Key. 


Path “DT”: Date 


Path dt all ows y ou to list the aopr log entries for a specified date. 
Complete the |cmd| [x] prompt by entering list «aopr log», path «dt» and 
specifying the date for which you want messages listed (December 8 in the 
example below). The date in the key field must be entered just as it would 
appear in the aopr log listing. All letters must be entered in uppercase. 

List Name aopr log Path dt Proof _ Filter by 

Key 08DEC _ 

The resulting list is illustrated in Figure A-7.3. The list begins with the 
first message logged on the date specified. 


AOPR log file (DT, 
Msg Date Time 


63 08DEC 02:44 
7 08DEC 02:44 
08DEC 02:44 
08DEC 02:44 


08DEC) 12/08/82 9:26 

From _ Text 

001,02,012 LDEV 0003 CU %170 IIO/HIIO I/O BUS ERROR #219 
001,02,012 LDEV 0033 CU %170 DOWN 
001,02,026 $DNC; I/O failed $C0.#T00: error 66 
001,00,066 $C001; File $C0.$#L01: error 66 


Figure A-7.3. aopr log Listing for December 8. 


Path “TX”: Message Text 

Path tx all ows y ou to list the aopr log entries by message text. 
Complete the |cmd| [x] prompt by entering list «aopr log», path «tx». In 
the key field, you may specify up to 10 characters of the text messages 
you wish listed. The message text in the key field must be entered just as it 
would appear in the aopr log listing. 
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This path allows you to list all the 
($zeus in the example below). 


List Name aopr log 
Key $ZEUS _ 


Path tx 


messages about a particular process 


Proof _ Filter by 


The resulting list is illustrated in Figure 9-4, below. 


AOPR log file (TX, 
Msg Date Time 
04DEC 10:55 
04DEC 15:00 
07DEC 20:33 
20DEC 13:53 


$ZEUS) 

From _ Text 

001,02,027 $ZEUS 
001,02,043 $ZEUS 
001,01,034 $ZEUS 
001,02,033 $ZEUS 


BACKUP created 
BACKUP created 
BACKUP created 

Can't send STARTUP message to 


12/08/82 9:26 


Figure A-7.4. aopr log Listing for Path «tx», Key «$zeus». 


Path “FR”: From 


Path fr allows you to list the aopr log entries by network node, cpu 
number, and process id number. Complete the IcmdI [x] prompt by enter¬ 
ing list «aopr log», path «fr». Entries in the key field will be ignored. 

List Name aopr log Path fr Proof _ Filter by _ 

Key _ 


The resulting list is illustrated in Figure A-7.5, below. Messages are 
listed in ascending order by network node and cpu number. 


AOPR log file (FR) 




12/08/82 9:26 

Msg 

Date 

Time 

From 

Text 




04DEC 

11: 00 

001,00,075 

$A304; 

Can't open $A3.#T04, Entry in 



04DEC 

11: 00 

001,00,060 

$SCHD; 

Backup process running 



08DEC 

09: 00 

001,01,034 

$ZEUS; 

Can't create $EMON: error 11 



08DEC 

09: 00 

001,01,033 

$ZEUS; 

Descendant abended $P001 



02 DEC 

13: 00 

001,02,033 

$ZEUS; 

Descendant abended $SEND 


3 

07DEC 

18: 00 

001,02,017 

LDEV 0038 I/O BUS ERROR #218 



Figure A-7.5. aopr log Listing Path «fr». 


Message Groups for Operator Messages 

If a message notification file entry exists, selected system messages 
can be sent to specific message groups. In order to do this you must first 
create a message group to which you want the messages sent. Display a 
list of groups ( IcmdI 0 for lgen list groups no path or key required). 
Position the cursor at a record in the list and execute IcmdI □ [f] to copy 
the form. A blank form is displayed as illustrated in Figure A-7.6. 


Copying record 

Group name 

User name 

System 



Figure A-7.6. Form for Message Group Definition. 


Complete the form as described below and illustrated in Figure A-7.7. The 
message group you create may have as many members as necessary. 
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group name —The name of the message group you wish to create (for 
example, aopr group). 

user name —The name of the user who is to be a member of this group, 
and to whom you wish messages to be sent. 



system —If the user to whom the messages are to be sent is on another 
logical system, you must specify the system name here. 


Copying record 



Group name AOPR GROUP 

User name RICK 

System 


Figure A-7.7. Completed Message Group Definition Form. 


Once you have created a group to which messages may be sent, you 
must determine which messages should be sent to the group members. 
Call up a list of the message notification file ( ICMDl fxI list «aopr groups»). 
A typical list is illustrated in Figure A-7.8. 


Operator 

Message 

1 

2 

3 

4 

5 

6 
7 


Figure A-7.8. List of Message Notification Groups. 

To specify that a message is to be sent to the message notification 
group, position the cursor at the desired message and enter fcMDl [f] to 
edit the form. When the form is displayed, enter the name of the group to 
which the message is to be sent (Figure A-7.9). 


Editing record 

Message 6_ Group AOPR GROUP 

Description Device up __ 

Figure A-7.9. Completed Message Notification Form. 

In Figure A-7.10, below, two messages have been selected for trans¬ 
mission to aopr group. Whenever these message are logged, they will be 
displayed on the vdts of the members of the group. 




Operator message alert groups 

Message Group Description 

12/08/82 13:46 

1 


Unexpected mount 


2 


Can't access label 


3 


I/O bus error 


4 


Device error 


5 


I/O retry 


6 

AOPR GROUP 

Device up 


7 

AOPR GROUP 

Device down 



Figure A-7.10. List of Message Notification Groups. 


message alert groups 


Group 


Description 
Unexpected mount 
Can’t access label 
I/O bus error 
Device error 
I/O retry 
Device up 
Device down 


12/08/82 13:46 


A 
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AOPR Error Messages 

The following messages may be given while you are using aopr. Most 

messages occur immediately following the command entry which generat¬ 
ed the error. 

“Backup cpu failure”— aopr’s backup abended in a cpu failure. 

“Backup open failed for”—The process can't talk to backup. 

“Backup process running”—This is intended as information only. 

“Backup stopped or abended”—The backup process has been stopped or 
has abended for some reason. 

“case statement index ouf of range”—Contact your SI I System Engineer. 

“checkopen can’t talk to backup”—The backup has probably abended. 

“checkpoint can’t talk to backup”—The backup has probably abended. 

“Fatal i/o error in”—There has been a hardware failure, the disk drive is 
not working properly, the file is full, etc. 

“High priority write failed”—Contact your Sll System Engineer. 

“I must have a process name”—Either the file does not exist or you do not 
have the authority to access it. 

“Primary cpu failure”—The primary process abended in a cpu failure. 

“Primary process abended”—The primary process has abended for some 
reason. 

“Primary process died before checkpointing”— Someone has stopped 
the primary process. 

“Primary process stopped”—The primary process has stopped for some 
reason. 
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SECTION A-8 

Process Scheduling 


Program «schedset» has two applications: 

1. Scheduling Programs for Use —making programs available to spe¬ 
cific users in the form of menus of programs (processes) and/or groups 
of programs; and 


2. Scheduling Programs for Execution —scheduling programs to run 
on specified days and/or at specified times. 

If defined for a user with program schedset, an alphabetic menu of 
programs and/or program groups is available when «/» is entered in 
response to the Sll Command Interpreter prompt. We refer to this as a 
Process List (Figure A-8.1), a process being a running program (a pro¬ 
gram becomes a process when the user starts it). Both program groups 
and individual program names may be in the list. 


Process list for 

SHIRLEY 

Typ 

Name 

Description 

Grp 

PRODUCTION 

Production utility programs 

Pro 

BUSY 

List busy items by system 

Pro 

FIXCHAR 

SII character library maintenance program 

Pro 

SCAN 

Spooling file perusal program 


Figure A-8.1. A User’s Process List. 



In this case one group and three individual programs are listed. To list 
the progr ams in the group production, the user points at that item and 
executes Icmdi [7] a second time. A similar list, entitled “Processes in 
group (appropriate name),” is displayed (Figure A-8.2) from which the user 
may select a program to be executed by pointing the cursor at it and 
entering icmdi [s] (start process). 


Processes in 

group PRODUCTION 

Typ 

Name 

Description 

Pro 

B 

List busy items by system 

Pro 

CDUMP 

Perform classified dump 

Pro 

FGEN 

Form generation program 

Pro 

LGEN 

List generation program 

Pro 

RGEN 

Report generation program 

Pro 

SCAN 

Spooling file perusal program 

Pro 

SUMMARY 

Summarize busy users and items 

Pro 

USERS 

List signed-on users and busy users/items 


Figure A-8.2. A Group Process List. 


In order for a a user to successfully start a process (open all appropriate 
files) that user must be able, by virtue of his Tandem user account, to 
execute it through Command Interpreter were he to have that authority. 


The process list is an important means of granting users the ability to 
run utilities that are otherwise out of their reach without Command Inter¬ 
preter authority. It permits the grouping of programs by user application 
and is an immense convenience to those users with Command Interpreter 
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authority who would be able to execute all of the named programs anyway. 

Use of Program SCHEDSET 

As stated at the beginning of this section, the program schedset is 
used both for the definition of menus of processes for individual users and 
for the scheduling of programs to run automatically. Figure A-8.3 displays 
the menu of schedset commands. 

This program uses the virgule («/» [diagonal, slash]) as a prompt char¬ 
acter. Most commands apply to both functions of the program. The follow¬ 
ing are exceptions: 

1 . the user and group commands apply only to user menus, and 


2. the schedule command applies only to program scheduling. 


/h 


FC 

Interactively edit last command 

HELP [(command)] 

Print long command descriptions 

EXIT (or EOF! ) 

Terminate execution of program 

PROGRAM (name) 

Define the named program 

DELETE (type) (name) 

Delete the specified entry 

LIST [type] [DETAIL] 

list all items [of the spec'd type] 

USER (name) 

Define access of a user 

GROUP (name) 

Define a group of programs 

SCHEDULE (name) 

/ 

Schedule the named program 


Figure A-8.3. Program schedset «Help» Menu of Commands. 


The Help command supplies more detailed help for each command. At 
the semicolon prompt enter «help» or «h» followed by the name of the 
command. The shortest unique abbreviation of a command may be used. 
In the case of this particular program, no two commands begin with the 
same letter, so a single letter suffices as an abbreviation: «l» for list, «s» 
for schedule. This simplifies input of the commands. Each command is 
dealt with separately below. 

EXIT Command 

The command «exit» (or «e») may be used to exit schedset and most 
other int eractiv e programs. However, the easiest method of exiting is by 
entering [ctrl| 0 («eof»). This command is also common to most pro¬ 
grams. 

PROGRAM Command 

Before a program may be scheduled or added to a menu or a group, it 
must first be defined with the Program command. Enter the command as 
follows: 

/p name 

where «name» is the name of up to 12 alpha and/or numeric characters 
(no special characters) that you wish to use in referencing the program in a 
user s process list. ? he name need not be the same as the program’s 
formal file name. Some programs like «b» (busy) have several useful 
functions (as specified in the startup message) and each version may be 
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named for its function; e.g., «b», «users», «summary». The name should 
be meaningful to users. If «lgen» is not descriptive enough, in users’ lists 
it may be called «listdesign». 


When a program name is entered for the first time, you will be asked to 
supply various details about it. Most of the requested information applies 
only to scheduled programs (as indicated below). For all other programs, 
at least the “Program file name” must be given. You will be prompted as 
follows: 


Program description: 

Enter an optional description of up to 44 characters. The description is 
used in users’ process lists and in the list command of this program. 


Program file name: 

Enter the file name of the program: 

$(volume name), (subvolume name), (disk file name) 

Network nodes are not supported; only local file names are permitted. The 
program does not check the validity of the file name. 


Important: It is up to you to make certain that it is legitimate. If it is not, an 
error will result when a user (or the scheduling monitor, if it is scheduled) 
attempts to start it. 


Note: 



If you enter Ictrli [y] (eof) without answering this prompt, the new 
program name will not be saved. Entering ictrli 0 as a response 
to any subsequent prompt will save any information entered or 
changed so far and will return the «/» prompt so you may enter a 
new command. You are invited to use this function to avoid further 
prompting. 


Should VCONTROL wait after process has stopped? 

Answer «y» for yes, «n» or Ireturni for no. This applies to program «b» 
(busy) and other programs which list information on the vdt. (This applica¬ 
tion is discussed later under the heading “Running Programs Non-interac- 
tively.”) Responding “yes” to this question gives the user the opportunity to 
view the list produced by the program. The program is exited and the 
screen is cleared only when the user presses the Icmdi key. 


Startup message? 

A message—normally a command, or a command string—given the pro¬ 
gram at the time the process is created, to be used by the process as it 
sees fit. For example, the scheduled process «refresh» (required on all 
systems) is really an execution of the program «pup» (Peripheral Utility 
Program) with the command (startup message) “refresh,” this being only 
one of the many functions of that utility program. 


Process name: 

Applies only to scheduled programs, and may be used as desired. 

CPU? 


Applies only to scheduled programs. It is normally not necessary, but you 
may specify the number of the cpu in which the process is to run. 


Priority? 

Applies only to scheduled programs. This priority is ignored for user-start¬ 
ed processes. Process «refresh» runs at priority 198. For all other 
scheduled programs please consult your Sll System Engineer for his 
recommendation. 


A-8.3 












Process Scheduling 


System Manager 


Default volume? 


Applies only to scheduled programs. The default volume to use when the 
process is created. For scheduled programs, this is the equivalent of the 
Command Interpreter default volume. 


Input file? 


Applies only to scheduled programs. The source of input commands/data, 
if any. An appropriate file is «$console» (console typer). 

Output file? 


Applies only to scheduled programs. Where messages, prompts, listings, 
etc., should be printed. Depends on program. An appropriate file is «$s» 
(spooler collector). 

TANDEM user name: 


Applies only to scheduled programs. Scheduled processes created by the 
scheduling monitor are treated as though they were system users. In some 
cases they may have to execute as a specific Tandem user in order to 
have access to the program file and the data files it opens. If a name is 
given you will have to supply the password: 


Password? 



At the end of this series of prompts you are asked: 

Schedule program NAME? 

Answer «y» for yes, «n» or (return! for no. If you answer yes, prompting 
will continue, beginning with “Which days?”, as described for the Schedule 
command. (You may choose to define a program with specifications that 
qualify it for scheduling, but [by not answering “yes”] not schedule it at this 
time.) 


In summary, here are the prompts given by the Program command: 

Program description: 

Program file name: 

Should VCONTROL wait after process has stopped? 

Startup message? 

Process name: 


CPU? 

Priority? 

Default volume? 
Input file? 
Output file? 
TANDEM user name: 

(Password?) 
Schedule program 


? 
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When a program name that already exists is entered with the Program 
command, a summary of the existing data for that program is listed (pro¬ 
gram refresh is used as an example): 


Program: REFRESH 

Description: Write system information to disk 

ISYSTEM.SYSTEM.PUP /IN $CONSOLE, OUT $0, PRI 198, NAME 
$FRESH/* 

Startup message: refresh 

Default volume is $SYSTEM.SYSTEM 

No ASSIGN message(s) and no PARAM message (s).f 

Executes as TANDEM user SUPER.S 

RETURN leaves a field unchanged! 


This line reports the file name, input file, output file, cpu (not specified 
here), priority and process name. 

t This data applies only to the assignments and parameters for use by a 
scheduled cobol program. It must be specified with the Tandem Com¬ 
mand Interpreter (comint). If you wish to schedule cobol programs 
written by your programming staff, please consult your SI I System Engi¬ 
neer. 

$ Indicates that you will now be prompted for changes to each field as 
described above. Answering l return l to a prompt leaves the data un¬ 
changed and presents the next prompt. At any time you may avoid 
further prompting by entering Ictru IyI. 


DELETE Command 

The Delete command removes the schedset definition of a program 
(abbreviated «p»), a user («u»), a group («g») or a schedule («s»). It has 
the following form: 

(type) (name) 


where the «type» of item is specified as p, u, g or s, followed by the 
«name» of the program, user, group or schedule. As insurance against 
error, you are prompted as follows: 

Delete (type) (name)? 


Only a «y» or «yes» response completes the deletion; «n» or Ireturn| 
means “no.” 


When a program name is deleted, all references to that program defini¬ 
tion for users, groups and schedules are also deleted. 

When a user name is deleted, only it is removed; the programs and/or 
groups that it references still exist. 

When a group is deleted, only that group name is removed; the program 
names it references still exist. 


When a schedule is deleted, all run times for the program are removed; 
the program definition is unaffected. 


LIST Command 


The List command prints the names and descriptions of all items of the 
type specified: 


/LIST [type] [DETAIL] 
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where «type» is the type of item—programs, groups, users, schedules—to 
be listed. If you do not specify a type, all items for all types are listed in this 
order: 

Currently scheduled programs 
Currently defined programs 
Currently defined groups 
Currently defined users 

The «detail» (or «d») modifier may be used only when a type is speci¬ 
fied. It lists the detailed information for all items: 

1. for schedules, all scheduled programs are listed with their run times; 

2. for programs, all programs are listed alphabetically, followed by their 
definition information; 

3. for groups, all groups are listed alphabetically with the programs as¬ 
signed to each group; 

4. for users, all users are listed alphabetically, followed by lists of their 
accessible groups and programs. For example: 

/I u d 

to list the details of all users. 

USER Command 

Programs and groups are made accessible to users, and this informa¬ 
tion is modified, with the User command. Enter the command followed by 
the new or existing user name: 

/u (name) 

If the name entered (“Ian,” for example) is not currently saved, you are 
prompted: 

User IAN has no accessible programs. 

To add or delete access to a program or group, enter its 
name. 

Program or group: 


Enter the name of a previously-defined program or group, followed by 
[return]. As long as you make entries, you will continue to be prompted 
indefin itely with “Program or group:” until you reply with IreturnI or 
|ctrl| [yT. either of which will return the «/» prompt for a new command. 

If programs and/or groups are already defined for the user whose name 
is entered, a summary of accessible groups and programs is given, fol¬ 
lowed by the “To add or delete ...” prompt. To add program or group 
names, enter ones that have not been listed for the user. To delete a 
name, enter one that has been listed; you are further prompted: 

Delete access to /'group' or 'program') (name)? 

Only a «y» or «yes» response finalizes the deletion; «n» or IreturnI 
means “no.” 

Following the addition or deletion of program or group names for a user, 
it is advisable to execute the User command a second time to confirm 
currently accessible groups and programs for that user. The fastest way of 
doing this is with the fc command, followed by two Returns: 
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/fc 

IRETURNl 
/uian 
IRETURNl 
User IAN 


etc. . .. 


GROUP Command 

Groups are created and program names are added or deleted with the 
Group command which operates in a manner similar to the User com¬ 
mand. Enter the command followed by the new or existing group name: 


/g (name) 

If the name entered (“Classified,” for example) is not currently defined, you 
are prompted: 

Description: 

Enter a description of up to 44 characters. 


To add or delete access to a program, enter its name. 
Program: 


As with the user command, you will continue to be prompted with “Pro¬ 
gram:” indefinitely, until you reply with [returni or ictrli (yJ, either of 
which will return the «/» prompt for a new command. 


If programs are already defined for the group whose name is entered, a 
list of the programs is given, followed by a prompt for a new description 
and the “To add or delete ...” prompt. To add new programs to the group, 
enter ones that have not been listed. To delete a program name, enter one 
that has been listed; you are further prompted: 


Delete access to program (name)? 


Only a «y» or «yes» response finalizes the deletion; «n» or Ireturni 
means “no.” 

After making additions or deletions, you may get a confirmation list of 
programs currently defined for the group by entering the fc command, 
followed by two Returns. 

SCHEDULE Command 

A program is scheduled for automatic execution with the Schedule 
command. Enter the command followed by the name of the program: 

/s (name) 


If the name entered (“Payroll,” for example) is not currently defined, you 
are prompted: 


Program PAYROLL is not currently scheduled 
Which days? 


You have the choice of responding with days of the week, or with specific 
dates of the month (you may not mix the two in a single specification). 
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If you respond with [return], 
message is printed: 


giving no specification, the following 


Daily runs assumed. 


Weekdays are specified by entering the names of the days, divided with 
commas—monday, tuesday, Wednesday, etc. Only as many characters 
need be entered as are required to distinguish the word. «m,» «w» and 
«f» are unique abbreviations of Monday, Wednesday and Friday; «t» and 
«s» are not unique. Tuesday and Thursday must be abbreviated as «tu» 
and «th»; and Saturday and Sunday must be abbreviated as «sa» and 
«su». 

Dates of the month are specified with numbers, divided with com¬ 
mas—1, 3, 5, 7, etc. Since these dates are monthly, you are cautioned to 
not enter numbers greater than 28. (If you enter 29, February will be 
skipped except on leap years; if you enter 30, February, April, June, 
September and November will be skipped.) 

Note: Specifications must be given for either of the parameters Period or 
Run time (not both). If both are omitted, the schedule will not be 
saved. These are required to arrive at specific execution time(s). 

Period? 


This specification, too, is optional. You may state how often the program is 
to be executed on the days/dates (or daily) previously specified. This value 
is specified in minutes: 15 = every 15 minutes; 60 = once an hour; 720 = 
every 12 hours, or twice a day. 

If a period is specified, you are prompted: 


Range? 


You may specify a range of times as hours of the 24-hour clock: «0100 
0600» means 1 a.m. through 6 a.m. If you specify no range, the following 
message is printed: 

Entire day assumed. 


If you have not specified a period you will be prompted for specific run 
times: 

Run time: 


You must specify at least one run time, either here or as periods within a 
range of time. Run times are entered as hours of the 24-hour clock: 0000 
= midnight, 0330 = 3:30 a.m., 1450 = 2:50 p.m. If you make an entry, 
the prom pt will continue to be presented indefinitely until you respond with 
IreturnI . which will revert to the «/» prompt. 


This is the end of the prompting. The specifications will now be saved 
and the program is scheduled. 


If the program whose name is entered with the Schedule command is 
already scheduled, a summary of the scheduling information is given, 
followed by the prompt: 
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Add or delete run times? 

There are three choices: 

1. «a» to add times, 

2. «d» to delete times, or 

3. ireturni to make no changes. 

If you specify add or delete, you will be given the “Which days,” “Period” 
and “Run time” prompts. 

Adding and deleting times must be done with separate executions of the 
Schedule command. This is to avoid confusion. Day/time and date/time 
combinations are unique. If you wish to change Wednesday at 0300 to 
Thursday at 0300, you must delete Wednesday in one pass and add 
Thursday and 0300 in a second execution of the command. The fc com¬ 
mand, followed by two Returns, provides a speedy means of reexecuting 
the last command. 

Example #1 : Our imaginary company has two pay periods per month— 
the 1st through the 15th, and the 16th through the end of the month. The 
payroll program computes and prints checks from employee records. 
We wish to schedule this program for the 1 st (payroll for 2 periods back) 
and the 16th of each month at midnight. It is assumed that: 1) the operator 
has prepared the line printer with blank check forms on the evening prior to 
each run, and 2) the computer room or the room containing the line printer 
is locked. The checks are ready for distribution on the mornings of the run 
days. 

We schedule the program as follows: 

Which days? 1, 16 
Per i od? none specified 

Run time: 0000 

The next time we execute the Schedule command for this program: 

/_s payroll 
Program: PAYROLL 

Program is run on 1, 16 at: 

00 : 00 

Add or delete run times? 


Example #2: It is required that program «refresh» run every 15 minutes 
on all systems. We specify this as follows: 

Which days? IRETURNI 
Daily runs assumed. 

Period? 15 
Range? IRETURNI 
Entire day assumed. 
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The run times are computed from the period within the range (entire 
day). Reexecuting the Schedule command for this program prints: 

/s refresh 


Program: REFRESH 


Program is run daily at: 


o 

o 

o 

o 

00: 

: 15 

00: 

: 30 

00: 

: 45 

02: 

: 00 

02: 

15 

02: 

: 30 

02: 

: 45 

04: 

00 

04: 

15 

04: 

: 30 

04: 

: 45 

06: 

00 

06: 

15 

06: 

o 

CO 

06: 

45 

08: 

00 

08: 

15 

08: 

30 

08: 

45 

10: 

00 

10: 

15 

10: 

30 

10: 

45 

12: 

00 

12: 

15 

12: 

30 

12: 

45 

14: 

00 

14: 

15 

14: 

30 

14: 

45 

16: 

00 

16: 

15 

16: 

30 

16: 

45 

18: 

00 

18: 

15 

18: 

30 

18: 

45 

20: 

00 

20: 

15 

20: 

30 

20: 

45 

22: 

00 

22: 

15 

22: 

30 

22: 

45 


Add or delete run times? 


01: 

: 00 

01: 

: 15 

01 

: 30 

01: 

: 45 

03: 

00 

03: 

: 15 

03: 

: 30 

03: 

45 

05: 

00 

05: 

15 

05: 

: 30 

05: 

45 

07: 

00 

07: 

15 

07: 

: 30 

07: 

45 

09: 

00 

09: 

15 

09: 

CO 

o 

09: 

45 

11: 

00 

11: 

15 

11: 

30 

11: 

45 

13: 

00 

13: 

15 

13: 

30 

13: 

45 

15: 

00 

15: 

15 

15: 

30 

15: 

45 

17: 

00 

17: 

15 

17: 

30 

17: 

45 

19: 

00 

19: 

15 

19: 

30 

19: 

45 

21: 

00 

21: 

15 

21: 

30 

21: 

45 

23: 

00 

23: 

15 

23: 

30 

23: 

45 


Running Programs Non-interactively 


Recall that in the discussion of the Program command it was pointed out 
that the prompt “Should vcontrol wait after process has stopped?” ap¬ 
plies to programs which list or print information on user’s vdt. Such 
programs are defined to run without user interaction (although under differ¬ 
ent circumstances they may be run interactively); they perform their as¬ 
signed task(s) and then exit automatically. 


Answering yes to the “Should vcontrol wait...” prompt, causes the 
display to remain undisturbed after the program exits. The user may roll 
through the list(s) printed by the program and press the Icmdi key when he 
is ready to return to the List of Processes. 


If this question were answered no, the vdt control process «vcontrol» 
would clear the screen and return to the List of Processes as soon as the 
program exits and the user would not have the opportunity to read the 
program’s output. 

When a wait is specified, the message “vcontrol waits after program 
stops” is printed in the summary of program data when the Program 
command is executed a subsequent time (following initial definition). 

The function of this prompt is, therefore, critical to the operation of 
programs that supply information to the user. 


Program «B» as an Example 

An obvious example of a program using this feature is «B». This pro¬ 
gram, which is not an interactive program, is able to report busy users and 
items in various ways depending on the startup message or command it is 
given at execution time. 


First, let us examine how the startup messages are entered and used 
when the program is executed with the Sll Command Interpreter. There 
are three possibilities: 


1. no command, 

2. the command «users», and 
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3. the command «summary». 

Since «b» is not a program with which the user may interact, the 
commands must be entered immediately following the program name 
as a startup message: 

;b 

When entered with no startup message, the program will list only active 
user/item combinations for each system with a summary of the number of 
signed-on users and the number of busy items for each system. An active 
user is one with a take displayed on his vdt. An active item is a take being 
displayed or one that has been submitted to a process such as «just», 
«spell» or «save» (all takes being processed or waiting to be processed). 


; b..users 

When entered with the «users» startup message, signed-on users are 
listed separately from active user/item combinations and a summary is 
also given. This is advantageous because it reports users who are 
signed-on but not currently accessing takes. Those users who are not 
considered to be “busy” may in fact be actively viewing a directory or an 
index, or executing an interactive program or combining stories from direc¬ 
tories. 

;b summary 

When entered with the «summary» startup message, the program lists a 
summary—for each logical system—of the number of signed-on users and 
the number of busy items. This summary is a useful measure of general 
system activity. 

Defining this Program for SCHEDSET 

Now we may apply our knowledge of how program «b» is designed to 
run to program definitions (one for each method) with the schedset Pro¬ 
gram command. We will assign each application a name matching its 
startup message. (Please consult your SI I System Engineer for the correct 
default volume name for your system.) 

First, we define the program to run without parameters: 

/p__b 

Program: B 

Program description: List__busy__items__by__system 
Program file name: $system.system, b 
Should VCONTROL wait after process has stopped? y 
Startup message? EOF! 

Next, we define the program to run with the «users» parameter: 

/p users 
Program: USERS 

Program description: List. busy users and items 
Program file name: $system.system.b 

Should VCONTROL wait after process has stopped? y__*o 
Startup message? users .p 
Process name: EOF! 

Finally, we define the program to run with the «summary» parameter: 


A-8.11 
















Process Scheduling 


Security System 


/p summary 
Program: SUMMARY 

Program description: Summarize ..busy ..users and ..items 

Program file name: ^system.system, b 

Should VCONTROL wait after process has stopped? jrjo 

Startup message? summary ?g 

Process name: EOF! 


These three “programs”— «b», «users» and «summary»— may now 
be made available to users who require this information. Not only is it more 
convenient and faster to obtain than by executing program «b» with Sll 
Command Interpreter, but this valuable information may be made available 
to users who do not have Command Interpreter authority. 

Program «SCHEDSET» as an Example 

A likely candidate for this application is program schedset itself. It is a 
convenient example because we have just seen how the List command 
operates interactively. Let us examine methods for obtaining a detailed list 
of users. 

If we were executing schedset interactively, we would enter (for clarity, 
no abbreviations): 

list user detail 


To execute the program non-interactively through the Sll Command Inter¬ 
preter, we would enter: 


;schedset. list user detail 


where «list user detail» is the startup message. The program will print the 
list of users and then exit. 

Now we may use the same startup message—«list user detail»—in 
defining a “program”—named «usermenus» for schedset: 

/ P. .usermenus 
Program: USERMENUS 

Program description: SCHEDSET_,grpups_^ 

Program file name: ^system, system, schedset 
Should VCONTROL wait after process has stopped? y xa 
Startup message? list, userdetail ;o 
Process name: EOF! 


Program «usermenus» will now be a convenient means of obtaining 
this user/program/group information. Be aware that adding this to a user’s 
List of Processes does not circumvent file security. Refer to Section A-4 
where we gave ownership of the data files used by program schedset to 
user sched.super. All of these files were secured in such a way that any 
user could read them, but only the owner (or a user on another system 
with the same id) could write to them. When schedset is executed, 
however, it opens all required files for reading and writing; the program has 
no way of foreseeing the user’s intention to only read. (Read access by all 
users applies only to lists accessed with the Index user command, where 
the access level of the list may still deny a user access.) Consequently, 
access to this program may only be given to users with the Tandem user 
name sched.super (id 101 , 255 ). To them it is a convenience only, since 
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these users would probably have Command Interpreter authority. 

Useful Lists 

Two structures are useful in listing schedset information with the Index 
user command: 


sched'grpacc (data file «$system.sched.users») and 
sched'access (data file «$system.sched.programs»). 

The paths for these structures are described under “Available Index Paths” 
in the System/55 User Commands Manual. 


SCHEDSET Error Messages 

The following error messages may be given while your are using sched¬ 
set. Most messages occur immediately following the command entry 
which generated the error. 


“Entry too long”—The name or description entered is too long. Names are 
limited to 12 characters, descriptions to 44 characters. 

“Fatal i/o error in [file name]”—There has been a hardware failure, the disk 
drive is not working, the file is full, and so on. Notify your System 
Manager. 

“Group with same name exists”—Group names must be unique. 

“Illegal group name”—Group names are limited to alpha and numeric 
characters in one word. No spaces are allowed. 



Illegal parameter”—The command requires a program, group, user, or 
schedule name following the appropriate type modifier. A character 
typed in the parameter part of the command is illegal. Names consist 
only of alpha and numeric characters. 


“Illegal program name”—Program names are limited to alpha and numeric 
characters in one word. No spaces are allowed. 

“Internal error in program”—A program error. Notify your System Manag¬ 
er. 


“Invalid defaults”—The «$(volume).(subvolume)» specified for the Default 
volume prompt of the Program command is in the incorrect format. 

“Invalid process name”—The name entered in response to the “Process 
name” prompt of the Program command is not in the proper format. 

“Invalid time format”—Applies to the “Range” and “Run time” prompts of 
the Schedule command. The time contains illegal characters or illegal 
values. 


“Missing parameter”—The command requires a program, group, user or 
schedule name following the appropriate type modifier. 

“No such entry”—The program, group, user, or schedule referenced has 
not been defined. 


“No such group”—The group named in the command has not been de¬ 
fined for SCHEDSET. 


“No such program”—The program named in the command has not been 
defined for schedset. 


“No such program or group”—The program or group named in the com¬ 
mand has not been defined for schedset. 
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“No such user”—The user named in the command has not been defined 
for SCHEDSET. 

“Not a unique command”—If more than one command begins with the 
same letters, enough characters must be typed to provide unique 
identification. (At present, no two commands begin with the same 
letter.) 


“Not a unique command modifier”—If more than one command modifier 
begins with the same letters, enough characters must be typed to 
provide unique identification. (Modifiers are program, group, user, 
and schedule. At present, no two of them begin with the same letter.) 

“open failed for [file name]”—Either the file does not exist or you do not 
have the authority to access it. Notify your System Manager. 

“Program file name must be specified"—An entry is required for the “Pro¬ 
gram file name” prompt of the Program command. 

“Program with the same name exists”—Program names must be unique. 

“To many assign messages to store”—Applies to the storage of cobol 
assign messages during program definition. Only ten messages are 
allowed. 


“Too many parameters to store”—Applies to the storage of cobol param¬ 
eter messages during program definition. Only ten messages are 
allowed. 


“Unexpected character”—An illegal character has been typed somewhere 
in the command line, preventing it from being interpreted. 

“Unrecognized command”—The characters of the first word typed on the 
command line do not match those of a schedset command. 

“Unrecognized command modifier”—Wrong syntax. The modifier speci¬ 
fied does not exist or was incorrectly abbreviated. (Modifiers are the 
types program, group, user and SCHEDULE. 

“User name must be specified”—The User command requires a new or 
existing user name to be specified. The Delete command, if modified 
Z by user, requires an existing user name. 
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B 

List Busy Users and Items 


B, or Busy, is a non-interactive utility process used to list busy system 
users and items, and to give a summary of process and server class 
activity, b is designed to be used by System Operators or computer 
maintenance personnel. Should it be necessary to kill or stop a vdt 
process or group of vdt processes, b enables the operator to determine 
how much disruption this might cause. 

Running B 

To run b, start Sll Command Interpreter and enter «b» in response to 
the semicolon prompt. 


Figure B-1.1. Starting Process B. 


When run with no parameters, b lists all users who are busy and 
indicates what they are currently reading, editing, or creating, b gives a 
summary following the list (Figure B-1.2). 


;b 

Users and Items in use for Editorial 
BILL ($A806) is reading Story 'Falklands' 

JOANN ($B205) is updating Story 'Indy 500' 

TED ($C209) is reading Story 'Wall Street' 

BOBC ($A609) is updating Story '#5599' 

BUTCH ($A103) is reading Story 'Users' 

DICK ($C304) has requested APSJ ($EAJ1) to process Story'#102' 
211 busy item(s) 

Users and Items in use for Advertising 
STEVE ($A002) is updating Story '#31860' 

SHIRLEY ($B606) is creating Story '#25277' 

SHARI ($A206) is reading Story '#23032' 

27 busy item(s) 



Figure B-1.2. Busy Users on Editorial and Advertising Systems. 


Available Commands 

There are six commands available for use with b. Each provides differ¬ 
ent information. 

1. users— lists all signed-on users 

2. group— lists signed-on users in a specified vdt group. 

3. find— lists a specified signed-on user 

4. summary— lists the number of users and busy items 
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5. stats —lists system statistics 


6. class —summarizes system statistics by server class 

B also allows you to filter or limit a list of busy users and items by 
entering «system» following a command. The syntax is shown below: 

b (command) system (system identifier) 


All commands can be entered using their shortest unique abbreviation. 
Note that in Figure B-1.3, «b users system editorial» has been shortened 
to «b u sy e». 


;b u sy e 


Users and Items in use for Editorial 

PURGE ($EPRG) is updating Story 

'#3271' 

STOCKS ($ESTX) 


WIRE CARBON ($SEND) 


UPI-WIRE ($WRUP) 


BILL ($A806) 


BUTCH ($A103) is reading Story ' 

Users' 

DICK ($C304) has requested APSJ 

($EAJ1) to process Story'#102' 

250 signed on user(s); 211 busy 

item(s) 


Figure B-1.3. Busy Users and Items in the Editorial System. 


B Users: List All Signed-On Users 

The «users» command provides a list of all users who are signed-on 
and indicates whether they are currently reading, editing, creating or have 
the terminal in the idle state. B gives a summary of system activity follow¬ 
ing the list of busy users (Figure B-1.4). 


;users 

Users and Items in use for Editorial 
JOANN ($B205) is updating Story 'Indy 500' 

TED ($C209) is reading Story 'Wall Street' 

DICK ($C304) has requested APSJ ($EAJ1) to process Story'#102' 

250 signed on user(s); 211 busy item(s) 

Users and Items in use for Advertising 
STEVE ($A002) is updating Story '#31860' 

SHIRLEY ($B606) is creating Story '#25277' 

SHARI ($A206) is reading Story '#23032' 

50 signed on user(s); 27 busy item(s) 

Figure B-1.4. Busy Users on Editorial and Advertising Systems. 


B Group: List Busy Users in a VDT Group 

B may be run to list busy vdt users in a specified vdt group within a 
system. The syntax of the command is shown below: 


b group (group name) 

have been 

py ■ To ,,st the busy users in the Copy 
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group, enter «b group copy». Figure B-1.5 illustrates how the resulting 
listing might look. 


;b group copy 

Users and Items in use from Group Copy for Editorial 
BRICKER ($C213) is editing Story '#14888' 

BEN ($B707) 

BOQUIST ($B602) is reading Story '#16163' 

LAUCHER ($C005) is updating Story '#17435' 

MULLER ($C113) is updating Story '#11461' 

Figure B-1.5. Listing of Busy Users for Group “Copy”. 


B Find: Locate a Specific User 

B allows you to locate a specified user with the find command. That is, 
to determine to which system he is signed on (if any), and whether he is 
reading, editing, creating, or has the terminal in the idle state. The syntax 
of the command is shown below: 

b find (user name) 


In Figure B-1 .6, b has located user “Charles”. 


;b find Charles 
In Editorial 

CHARLES ($D012) is updating Story 'Falklands' 

In Advertising 

CHARLES is not signed on. 

Figure B-1 .6. find Command to Locate User Charles. 

Note that Charles is signed on to the Editorial system only. While it is 
rare that a user would be signed on to more than one system simulta¬ 
neously, it is permitted. In that case, the information spelled out for each 
system would indicate the user, terminal id, and function being performed. 
For example, if Charles were signed on in both Editorial and Advertising, 
the find command would locate him as shown in Figure B-1.7. (If a user is 
signed on to more than one vdt in one system, only one sign-on will be 
noted.) If the find command is entered without specifying a user’s name, b 
logs the message “Missing user name” and lists all busy users and items 
as in Figure B-1.2. 


; b. f ind..Charles 
In Editorial 

CHARLES ($D012) is updating Story 'Falklands' 

In Advertising 

CHARLES ($A702) is reading Story '#13069' 

Figure B-1.7. find Listing for User Signed on to Multiple Systems. 
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Summary: List Summary of Busy Users 

The « summary » command provides a brief description of system ac¬ 
tivity. The names and locations of individual users are not listed (Figure 
B-1.8). 


;b summary 

Users and Items in use for Editorial 
250 signed on user(s); 211 busy item(s) 

Users and Items in use for Advertising 
50 signed on user(s); 27 busy item(s) 

Figure B-1.8. A Summary of Busy Users And Items. 


B Stats: List Process and Server Class Statistics 

The «stats» command lists all processes and server classes for each 
system, the number of requests made to each process and server class, 
the total time it has taken to comply with those requests, and the average 
response time (Figure B-1.9). 

The total usage figure (requests) and total time count (time) is begun at 
cold start. Some process and server class statistics display a two-part 
average time. For example the statistics for process $eprf (Figure B-1 .9) 
give an average of 5.16 + 4.98. The first figure (5.16) indicates the 
average service time required for proofing a take. The second figure (4.98) 
is the amount of time a job in the process was queued before running. In 
the case of $eprf, it took an average of 5.16 seconds for each proofing to 
complete, and each job was queued approximately 4.98 seconds before 
being addressed. 


;b stats 

Statistics for Editorial 

Process: $EL6 Server class: L606 

Requests: 1 Time: 6.32 Average: 6.32 + 2.54 

Process: $EPRF Server class: PROOF 

Requests: 396 Time: 2046.85 Average: 5.16 + 4.98 

Process: $ESV1 Server class: SAVE 

Requests: 82 Time: 1483.88 Average: 18.09 + 0.73 

Statistics for Advertising 

Process: $CAJ1 Server class: APSJ 

Requests: 3 Time: 8.84 Average: 2.94 + 0.03 

Process: $CDTA Server class: DATA 

Requests: 0 Time: 0.00 

Process: $CPRF Server class: PROOF 

Requests: 1 Time: 2.72 Average: 2.72 

Process: $CSVE server class: save 

Requests: 5 Time: 23.55 Average: 4.71 -F 0.02 

Process: $CSPL Server class: SPELL 

Requests: 0 Time: 0.00 

-- ; - - - - -- 

Figure B-1.9. System Process and Server Class Statistics. 

B Class: Summarize Statistics by Server Class 

The «class» command summarizes statistics for server classes for 
each system. The display includes total usage (requests), average re- 
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might appear as illustrated in Figure B-1.10. 


; b__class system e 
Summary statistics for Editorial 


CLASS 

SERVERS 

REQUESTS 

AVERAGE 

DELAY 

APSH 

1 

15 

2. 75 

0. 08 

APSJ 

1 

20 

7. 55 

0. 01 

PROOF 

1 

39 

1.54 

1. 44 

QUME 

1 

85 

6. 92 

7. 16 

QUMEH 

1 

0 



QUMEJ 

1 

103 

12. 92 

0. 14 

SAVE 

2 

474 

10. 08 

0. 02 

SPELL 

1 

16 

34. 70 

0. 01 


Figure B-1.10. Server Class Statistics for an Editorial System. 

B Error Messages 

The following messages may be given while you are using b. Most 

messages occur immediately following the command entry which generat¬ 
ed the error. 

“Fatal i/o error in (file name)—There has been a hardware failure. Notify 
your System Manager. 

“Missing system specifier”—You have used the system command without 
specifying a system. 

“missing user name”—You have used the find command without specify¬ 
ing a user name. 

“No startup message found ”—b did not receive a startup message. Try 
again. 

“Open failed for (filename)—Either the file does not exist, or you do not 
have the authority to access it. 

“Unknown option specified”— b could not decipher the command you 
entered. 
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SCAN 

The Spooler Perusal Process 


The System/55 spooling system serves as a buffer between vdt output 
functions (output, fCMDj |o|; proof, IcmdI (pJ) and the destination output 
device. When a story is output to a device, it goes first to the spooling 
system which monitors the status of all output devices. 

If the device is unavailable because it is currently processing another 
story or is off-line, stories which have been sent to that device are held in a 
queue in the spooling system until the device is ready. When the device 
becomes available, the highest priority story is sent from the spooling 
system. Thus, stories may be output or proofed whether or not the print 
device is actually ready to process them. 


Some System/55 processes (for example cdump, the classified dump 
process) allow the user to specify whether output is to be sent directly to 
the device on which it is to be printed, or if it is to be held in the spooling file 
until released. That process also allows the user to specify that the output 
is to be held in the spooling system after it has been filmed to allow jobs to 
be rerun to correct errors at the output end. 


For a description of the spooling system, please see the Tandem 16 
Spooler Management Guide (ti 6/8094). 


SCAN 

SCAN is an interactive utility process for examining jobs in the spooling 
system before they are sent to the output device. It allows proofreading 
(without inspecting printouts), correcting, and combining, thus saving pa¬ 
per (or film), printer ribbons, and wear and tear on printers. 

SCAN allows you to perform any of the following functions on jobs which 
have been sent to the spooling system: 

• Release a job to its default device 

• Release a job to to a different device 

• Give a job a new priority to put it ahead of less important jobs or behind 
more important jobs 

• Change the number of copies to be produced 

• Search for errors 


• Examine a compiler listing before making a decision to print or proof it 

• Monitor job status change 

• Alter a job’s location 


Running SCAN 


SCAN can be started from the Sll Command Interpreter, or from a list of 
processes. 
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To display a more detailed description of a specific command enter 
«help (command name)». 


The Help Command 

SCAN has a help command available. To use it, start the process and 
enter «help». All the available commands and a brief description of each 
will be listed (Figure B-2.1). 


-help 


FC 

Interactively edit last command 

HELP [command] 

Print long command descriptions 

EXIT (or EOF!) 

Terminate execution of process 

DEVICE [name] 

Get device information 

STARTCOL [column] 

Display or set starting column 

NUMCOL [width] 

Display or set width 

ALL 

Clear the job location mask 

ONLY [mask] 

Display [or set] the location mask 

GROUP option 

Apply option to set of jobs 

WAIT [job] 

Wait for the job to change state 

JOB [number] 

List or select jobs 

JDETAIL [number] 

List or select jobs (detailed) 

JREPORT [number] 

List or select jobs (report name) 

JFORM [number] 

List or select jobs (form name) 

INFO [job] 

Display/set current job 

IDETAIL [job] 

Display/set current job (detailed) 

COPIES count 

Change number of copies to print 

DELETE 

Delete current job from spooler 

HOLD ON/OFF 

Change hold status of job 

AFTER ON/OFF 

Change holdafter status of job 

LOCATION group.dest 

Change location of job 

PRIORITY pri 

Change priority of job 

REPORT report name 

Change report name of job 

FORM form name 

Change form name of job 

LIST [/out/] range 

List contents of the current job 

LHEX [/out/] range 

List current job in hex 

FIND [string] 

Search for the specified string 

XS range 

Begin TAL program cross-reference 

XF [/out/] 

Print TAL Program cross-reference 


Figure B-2.1. scan Help Command. 


Exiting SCAN 

You can exit scan at any time by entering fCTRj 0. The process will log 
the message “EOF!” and exit. You can also stop the process by enterinq 
«exit» in response to the scan hyphen prompt. 


Available SCAN Commands 


after {on/off}— Changes the holdafter status of the current job. Can 
be used only while a job is selected. See also “Differences Between 
HOLD and AFTER” later in this section. 


all Clears the job location mask (see “only”). 

copies (number) Changes the number of copies which are to be made 
of the currently selected job. Can be used only while a job is selected. 

delete— Deletes the currently selected job from the spooling system. Can 
be used only while a job is selected. 
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device If no parameters are entered, the command lists all devices 


controlled by the 


spooling system (Figure B-2.2). 


-device 
Device 
$A4. #T15 
$EXOR 
$J 

$APS1 

$APS2 

$APS3 

$LP 

$PUNCH 

$QUME1 

$QUME2 

$RP 


State 

Proc 

Off Line 

$SPLP 

Waiting 

$SPLP 

Waiting 

$JOBS 

Waiting 

$SPLP 

Busy 

$SPLP 

Off Line 

$SPLP 

Waiting 

$SPLP 

Waiting 

$SPLP 

Busy 

$SPLP 

Waiting 

$SPLP 

Waiting 

$RPRT 


Figure B-2.2. scan Device Status List of all Devices. 


If a specific device name is entered, device reports the device status 
followed by a list of jobs waiting to be sent to the device (Fiqure 
B-2.3). 


-device $qumel 

Device 


State 

Proc 

$QUME1 


Busy 

$SPLP 

Job Group Dest 

Pages 

Wait 

Report 

246 #QUME DEFAULT 

3 

00:00:28 

SHARON 


Figure B-2.3. scan Device Status Report for Device Qumel. 



exit —Stops the scan process. 
fc —Standard Tandem fix command. 

find [string]—Searches forward in the job from the current line looking for 
occurrences of the specified string. If no string is specified, the last 
string, if any, is reused. The search terminates when the end of the 
job is reached, a match is found, or the IcmdI key is pressed. 

If a match is found, the matching line is displayed on the terminal. 
Delimiting slashes (/) must be used when searching for leading or 
trailing spaces which would otherwise be ignored. If the slashes are 
used, they are not included in the search string. 

This command can be used only while a job is selected. 

Example: 

To find errors in a job: 

FIND *** 


FORM (name)—Changes the form name of the current job. Can be used 
only while a job is selected. See also “Report and Form Names.” 


group —Allows the user to apply a scan command to the group of jobs 
defined by the current job location mask. A mask must have been 
previously specified with the only command. The syntax of the 
group command is listed below: 


GROUP (command) (parameter) 
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Examples: 


To change the number of copies for a group: 

GROUP COPIES (value) 


To delete a group from the spooling system: 

GROUP DELETE 


To take a group off hold: 

GROUP HOLD OFF 


To change the location of a group: 

GROUP LOCATION (group.dest) 

To change the priority of a group: 

GROUP PRIORITY (value) 

To change the report name of a group: 

GROUP REPORT (name) 

To change the form name of a group: 

GROUP FORM (name) 


For more information about the commands used with the group 
command, see the description for that particular command. 

hold— Changes the hold status of the current job. Can be used only while 
a job is selected. See also “Differences Between hold and after” 
later in this section. 


idetail —Displays a detailed description of the specified job (Figure B-2.4) 
and selects that job as the current job. 


“idetail 390 

Job State Pages Cop Pri Group Dest Report 

390 Hold 43 1 4 #Default SHARON 

Collected by $S from 4/05/82 16:38:21 to 4/05/82 16:43:05 
Owned by 254,255, Hold after 


Figure B-2.4. Detailed Information for Job 390. 


jdetail— If no job number is given, jdetail displays a detailed list of all 
jobs currently in the spooling system. 

If a job number is specified, that job is selected as the current job. 

jform— Causes all subsequent job status lists to include the form name 
of the job rather than report name. If a job number is supplied, jform 
makes that job the current job. If no job number is given, the current 
job is not changed. In either case, the status of the current job is 
displayed. See also “Report and Form Names” later in this section. 

job —With no parameter, lists jobs currently in the spooling system. If a 
parameter is supplied, that job is selected as the current job. 


-j ob 
Job 

State 

Pages 

Cop 

Pri 

Group 

Dest 

6 

Ready 

30 

1 

4 

#PD 

UTILITY 

7 

Hold 

34 

1 

4 

#DEFAULT 


8 

Print 

23 

1 

6 

#QUME 

DEFAULT 

12 

Ready 

19 

1 

4 

#TCU 

TANIO 

22 

Open 


1 

4 

#APS 

MAIN 


Report 
SII SUPER 
SII SUPER 
SHARON 
SII SUPER 
SII SUPER 


figure B-2.5. scan Job Status Report. 


The number of pages in each job, the number of copies requested 
the priority, the group and destination are also listed. 
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Together the group and destination are known as the job location. A 
location is the logical destination of a job. Each job is assigned a 
location when it enters the spooling system. The job is printed on a 
device connected to the location. 


Location names have two parts: a group name and a destination 
name. The group name is always preceded by #. For example, the 
location names in Figure B-2.5 are: #pd.utility, #default, 
#qume.default, #tcu.tanio, and #aps.main. #pd is the group 
name while pd.utility is the name of a location in #pd. 


jreport— Causes all subsequent job status lists to include the report 
name of the job instead of the form name. See also “Report and Form 
Names.” 


lhex [/<out file)/] (range)—Identical to the list command, except a hexa¬ 
decimal representation of the data is displayed along with the ascii. 
Can be used only while a job is selected. 


list [/(out file)/] (range)—Lists the contents of the currently selected job. 
An optional output file specification may be included to send the 
output to a location other than the terminal. 


The output specification consists of the file name enclosed in slashes. 
There is no out keyword. 


Jobs which have been justified and output to typesetters (aps, L606 
and so on) should not be displayed on the terminal with the list 
command. These jobs contain character codes and commands for 
the typesetter which cannot be converted for display—and can cause 
vdt malfunction. 


The range specification consists of one or two page specifications 
separated by a slash. This figure indicates the range of pages to be 
listed. For example entering «list 2/6» will display pages 2 through 6 
of the current job. If only one page specification is given, only that 
page is listed. For example, «list 9» will list only page 9. 

A page specification may be absolute, «list 9», or relative. A relative 
page specification may be relative to the current page, indicated by 
an asterisk, or relative to the last page, indicated by the letter «l»; «list 
l» lists the last page of the job. For example, «list *-1/*+1» lists the 
page preceding the current page, the current page, and the page 
following the current page. If the current page is 6, «list *-1/* +1» lists 
pages 5, 6, and 7. «list 1/l» will the list the current job beginning with 
the first page and ending with the last. 

The list command with no parameters displays the current page 
number. 

This command can be used only while a job is selected. 


location [group.destination]—Changes the location of the current job 
and sends the job to that location. If no change to the location is 
specified, the job is sent to its default location. This command can 
only be used while a job is selected. 


numcol (width)—With a value supplied, changes the display column 
width to the specified value. With no parameters, the current width 
value is displayed. When not specified, lines are truncated at the last 
display column of the vdt. 
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only [mask]—With no parameters, displays the current job location mask. 
If a parameter is given, the location mask is set to that parameter. 
The location mask is used by the job and wait commands to select a 
subset of the job list for display purposes. Only those jobs whose 
location group matches the location mask will be displayed. 

priority (value)—Changes the spooling priority of the current job. This 
command can only be used while a job is selected. 


report (name)—Changes the report name of the current job. This com¬ 
mand can only be used while a job is selected. See also “Report and 
Form Names” later in this section. 


startcol (column number)—With no parameters specified, lists the cur¬ 
rent starting column number. If a value is given, the starting column 
number is changed to that value. This command has the effect of 
moving all display lines to the left, beginning the display in the speci¬ 
fied column (for example, to display the second half of a report). 

wait (job)—With no parameters, waits for any job in the spooling system 
to change state. When a job changes state, the jobs currently in the 
spooling system are listed. 

If a job is specified, the process waits for the specified job to change 
state. When it does, the process prompts for the next command. 


xs This command should be used only by qualified programming per¬ 
sonnel. The xs command is similar in syntax to the list command. 
However, instead of listing the selected pages from the current job, xs 
searches them to locate references to identifiers. The references are 
placed in a sort file for creation of a cross-reference listing. Only tal 
compiler listings may be used. 


The xs command takes a range specification but not an output file 
specification (see xf below). 


xf This command should be used only by qualified programming per¬ 
sonnel. The xf command completes a cross-reference listing and 
should be given after one or more xs commands, which may be for 
the same or many listings (up to 50). This command requires an 
output file specification in the same form as the list command, but it 
does not take a range specification. 

The xf comm and may be aborted after the sort is complete by press¬ 
ing the [cmdI key twice. 


Differences Between HOLD and AFTER 

When a job is placed on hold with the «hold on» command, it may not be 
sent to the printing (or typesetting) device with the location command A 
job is released from hold with the «hold off» command. 

The hold-after flag is turned on with the «after on» command. This 
means that the job will be put on hold following printing (or typesetting) 
This flag is in effect until turned off with the -after off* command; the job 
will leave the spooling file the next time the location command is used on 
the job, or when the job is deleted. 

H ° LD be released for printing with the «hold off» com¬ 
mand. The job is taken off hold (made “Ready”). If the after flaq is on the 
job is placed back on hold following printing. 9 ’ 
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The after on flag is therefore useful for jobs like the classified dump 
which take a long time to process. If there is a failure at the typesetter or 
the film processor, the job can be sent to the device again after the 
problem has been fixed. Finally, once satisfactory output has been 
achieved, the job may be deleted with the delete command. 


Report and Form Names 

For jobs that are proofed or output to a typesetting device, the report 
name is always the user’s name. Jobs which are queued to be complied 
(styl, rgen, and so on), list the user name as the report; following 
compilation, when the job is ready, the user’s Tandem account number is 
listed. The report name is for information purposes only; the system does 
not interpret it. 


Form names, on the other hand, are used to control output to a physical 
sub-device location. In System/55, form names are used to conserve 
typesetter film. They are defined in sub-device records for a typesetter and 
might typically be called narrow or wide (or class or edit) to represent 
specified maximum film widths. All jobs which do not have measures 
exceeding that specified for narrow film are assigned that form name by 
the typesetter output module; all wider jobs are assigned a name of wide. 


Physical device locations are given form names with the Tandem 
spoolcom process. Any job with a form name not matching the form name 
of a physical device is blocked from output. When the form name of the 
device is changed, all jobs with that form name are sent to the device. 
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SECTION B-3 

LINKUP Process 


LINKUP allows you to obtain information about the program file as 
described in “Process Revision Levels”. 


Process Revision Levels 


All Sll processes are identified by a product number which includes 

Process Revision Level information. The string consists of four fields: 

1. The product number. This number is composed of a letter which identi¬ 
fies the origin of the product and a four-digit software product number. 
There are three types of product numbers, as follows: 

«t» for Tandem product, with the four-digit Tandem product number; 
«s» for Sll product, with a four-digit Sll product number; and 
«u» for unsupported Tandem products (for which Sll has the source), 
with a four-digit Sll product number. 


2. The lowest level Tandem monitor revision at which this process will run. 
This field is changed only when a Tandem monitor is installed which 
requires a change to the process in order to make it run on the new 
monitor release. All processes start with «eoi » in this field to reflect that 
monitor release. 


3. A three-digit Version Number (initially zero), which is incremented 
whenever a “significant” change is made to a process (e.g., changes 
which make it incompatible with the previous version, changes which 
would require a new release of the documentation, etc.). Generally, a 
bug fix is not considered a version level change, but rather an edit level 
change (reflected in the next field). The edit level should be reset to 
zero whenever the version level is incremented. 


4. A three-digit Edit Level (initially zero) which is incremented every time a 
change is made to a process. This necessitates changing the linkup 
for a process each time a change is made to that a process. In addition, 
the Revision History of the process (maintained in the source) is updat¬ 
ed, noting the new Edit Level with an explanation of the change. 


Product Number Example 


S0009.E01.001 (008) 


«S0009.» identifies this process as Sll software product #9. 

«E01.» identifies Tandem monitor revision eoi as the lowest Tandem 
monitor revision with which this process is compatible. 

«00i» is the current version level of the process, the first significant 
change to it. 

«(oos)» is the current edit level of the process, the eighth change since 
version ooi took effect. Edit levels reflect minor changes. 
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How to Determine the Revision Level of a Process 

Revision level information is contained in the code of all processes in 
System/55. This information is user-accessible so that at any time you can 
determine what version of a process is installed at your site. Knowing the 
revision level of a process is especially important for troubleshooting in 
case of difficulties which may result from the incompatibility in versions of 
two processes. It is also essential for installing updates to a site’s software. 

To determine the version and edit level of a program in your system, 
execute the following in Sll Command Interpreter (be sure to enter the full 
program file name in the «linkup info» command; cupdateh is used as 
an example. System and process revision information is in boldface.) 


:linkupinfo$system.sii.cupdateh 
Object file name is $SYSTEM.SII.CUPDATEH 
Main procedure is CUPDATEH 
9902 words of global data 
11 data pages requested 
18360 words of user code 
72 words of PEP 

37557 is execution address (octal) 

System revision level: SII.E02 Sept 1981 
Process revision level: S0009.E01.001 (019) 
Build date: 10/30/81 10:37:13 


Figure B-3.1. linkup info for cupdateh. 
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SECTION B-4 

PSTAT 


PSTAT displays useful information about a process. When executed it 
prints the contents of its process control block and lists all open files. If the 
file is open for no-wait i/o, pstat lists the information on outstanding 
requests for the file. 


Executing PSTAT 

PSTAT can be executed from Sll Command Interpreter. At the semico¬ 
lon prompt enter «pstat» followed by the name (or cpu, pin number) of the 
process for which you wish to display statistics. 

In Figure B-4.1 below pstat has been executed for a Coyote terminal 
process. 


;pstat„$a501 

Process $A501 (0,64) was created by: $ZEUS 
Creation ID = 254,255 and process ID = 255,255 
Creator may stop process, and no one has tried. 

Waiting for LREQ, LHREQ, LDONE 
Has received LCAN 

S = 033741 P = 007747 E = 002507 L = 033737 

SHORT = 0, LONG = 0, 10 = 0, DISC = 0, CB = 0, LCB = 1 

Program file name: $SYSTEM.SII.ECONTROL 

I/O was last done to file number 16 

Last error was error number 40 

File 0 is IRECEIVE (R/W, S) 

Request 0 is READUPDATE for 2048 bytes 
File 1 is $A05. #L01 (R/W, E) 

Request 0 is WRITEUPDATE for 0 bytes 
File 2 is $A05.#R01 (R/W, S) 

File 5 is $EFIO (R/W, S) 

File 6 is $EGOD (R/W, S) 

File 7 is $EGOD (R/W, S) 

File 8 is $EMSG (R/W, S) 

File 9 is $EVPT (R/W, S) 

File 10 is $EVGT (R/W, S) 

File 11 is $SYSTEM.EDITOR.HEADER (R/W, S) 

File 12 is $EUPD (R/W, S) 

File 13 is SSYSTEM.EDITOR.STRINGS (R/W, S) 

File 14 is $ETW (R/W, S) 

File 15 is $ETR1 (R/W, S) 

File 16 is $STAT (R/W, S) 

File 17 is $SYSTEM.VPEND.A501 (R/W, S) 

File 18 is $EFIL (R/W, S) 


Figure B-4.1. pstat for Coyote Terminal Process. 
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Figure B-4.2 illustrates pstat executed for the receive process $ercv. 


; pstat Jjercv 

Process $ERCV (1,55) was created by: $ZEUS 
Creation ID = 245,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Waiting for LREQ, LHREQ 

Has received LCAN 

Will timeout after .58 seconds. 

S = 005767 P = 007747 E = 002407 L = 005765 

SHORT = 0, LONG = 0, IO = 0, DISC = 0, CB = 0, LCB = 0 

Program file name: $SYSTEM.SII.RCVR 

I/O was last done to file number 0 

Last error was error number 40 

File 0 is $RECEIVE (R/W, S) 

Request 0 is READUPDATE for 2048 bytes 
File 1 is $0 (R/W, S) 

File 4 is $ETW (R/W, S) 

File 5 is $EUPD (R/W, S) 

File 6 is $EGOD (R/W, S) 

File 7 is $SYSTEM.EDITOR.HEADER (R/W, S), last error was 1 


Figure B-4.2. pstat for ercv. 


Executing PSTAT on a TNSII System 


When pstat is executed on a TNS II system, you are informed when the 
specified processes is in debug (Figure B-4.3). 


;pstat $a409 

*** PROCESS IS IN DEBUG ON $TERM4 *** 

Process $A409 (1,98) was created by: $ZEUS 
Program file name is $SYSTEM.SII.ECONTROL 
Creation ID = 254,255 and process ID = 255,255 
No one may stop process, and no one has tried. 

Waiting for LDONE 
Will not time out 

Initial priority was 140 and current priority is 140 

S = 042502 P = 067255 E = 002417 L = 042501 

LISTEN LCB's reserved: 0, LINK LCB’s reserved: 0 

LISTEN LCB’s in use: 0, LINK LCB’s in use: 1 

I/O was last done to file 1 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 2048 bytes 
File 1 is $A4.#L09 (R/W, E) 

File 2 is $A4. #R09 (R/W, S) 

File 5 is $EFIO (R/W, S) 

File 6 is $EVPM (R/W, S) 

File 7 is $EGOD (R/W, S) 

File 8 is $EGOD (R/W, S) 

File 9 is $EMSG (R/W, S) 

File 10 is $EVPT (R/W, S) 

File 11 is $EVGT (R/W, S) 

File 12 is $SYSTEM.EDITOR.HEADER (R/W, S) 

File 13 is $EUPD (R/W, S) 

File 14 is SSYSTEM.EDITOR.STRINGS (R/W, S), last error was 1 
File 15 is $ETW (R/W, S) 

File 16 is $ETR (R/W, S) 


Figure B-4.3. pstat Executed on TNS II System. 
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If the specified process is not in debug when pstat is executed, the first 
line of the display (the debug message) is omitted. 

PSTAT Error Messages 


The following messages may be given while you are using pstat. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 


“Fatal i/o error in [file name]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 

“No Startup message found”— pstat did not receive the startup message 
it expected from the Sll Command Interpreter. You may get this 
message if you press Icmdi before pstat executes. Try executing 
pstat again. If you get this message a second time, contact your Sll 
System Engineer. 

“No such cpu, pin”— The cpu, pin you specified is not running. For exam¬ 
ple, you would get this message if you entered «pstat 3,4» on a two 
processor system. 

“No such process-pair name”—You have entered an invalid process-pair 
name in the pstat command line. 


“open failed for [filename]”—Either the file does not exist or you do not 
have the authority to access it. 


“pstat must run in same system as”—You cannot pstat a process on a 
remote system. You must run pstat on that remote system. 



Unable to new process into correct cpu”—pstat couldn’t get to the cpu 
in which the process is running. 
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SECTION B-5 

FSTAT Process 


FSTAT lists processes which have a named file open. If you cannot 
open a file or device because it is in use, fstat can tell you which 
processes have the file open. 

If you attempt to fstat a file which does not exist, the semicolon prompt 
is returned. No error message is given. 


Executing the Process 

FSTAT can be executed from Sll Command Interpreter. At the semi-co¬ 
lon prompt enter «fstat» followed by the file name and Ireturni . 


;fstat 
00,064 

$a0. #t06 
$A306 254,255 

$TERM4 

$SYSTEM 

. SII 

.ECONTROL 

01,034 

254,255 

$A3 

SSYSTEM 

.SII 

.Cl 


Figure B-5.1. Sample fstat for an ET/960 Terminal File. 


To fstat each side of a Coyote Terminal right (r), and left (I). 


;fstat 
00,013 

$a5. #r01 
$A506 254,255 

SCONSOLE 

SSYSTEM 

.SII 

.ECONTROL 

;fstat 
00,013 

$a5. #101 
$A506 254,255 

$CONSOLE 

SSYSTEM 

. SII 

.ECONTROL 


Figure B-5.2. Sample fstat for a Coyote Terminal File. 



FSTAT can be run for any file on the system. Figure B-5.3 below 
illustrates fstat of the header file $data.editor.header. 


;fstat 

$data. 

editor.header 




00,044 

$A405 

254,255 

STERM4 

SSYSTEM 

. SII 

.ECONTROL 

00,067 

$A406 

254,255 

STERM4 

SSYSTEM 

. SII 

.ECONTROL 

00,069 

$PL2H 

254,255 

STERM4 

SSYSTEM 

.SII 

.JUST 

00,072 

$A414 

254,255 

STERM4 

SSYSTEM 

.SII 

.ECONTROL 

00,076 

$A402 

254,255 

$TERM4 

SSYSTEM 

. SII 

.ECONTROL 

00,080 

$PPSJ 

254,255 

STERM4 

SSYSTEM 

. SII 

.JUST 

00,087 

$PSPL 

254,255 

STERM4 

SSYSTEM 

. SII 

.SPELL 

00,098 

$PVPT 

254,255 

STERM4 

SSYSTEM 

. SII 

.VPUTGET 

00,100 

$PSV1 

254,255 

STERM4 

SSYSTEM 

. SII 

.SAVE 


Figure B-5.3. fstat for $data.editor.header. 


FSTAT Error Messages 


The following message may be given while you are using fstat. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 


Child process abended”— 


Contact your Sll System Engineer. 


“cpu failed during processing”—The cpu failed while you were attempting 
to run FSTAT. 
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“Illegal logical device number”—Recheck your entries on the command 
line. 

“Invalid format for file name”—You have entered the file name incorrectly. 

“i/o error for [filename]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 

“open failed for [filename]”—Either the file does not exist or you do not 
have the authority to access it. 

“newprocess failed”—FSTAT cannot run. 

“No startup message found”— fstat did not receive the startup message 
it expected from the SI I Command Interpreter. Try executing fstat 
again. If you get this message a second time contact your Sll System 
Engineer. 

“Remote deviceinfo failed for"— fstat could not communicate with a re¬ 
mote system. 

“There is no device with that name”—You have specified an invalid device 
name on the command line. 

“Unable to open child”—Contact your Sll System Engineer. 

“Unable to send startup message to”—Contact your Sll System Engineer. 



-Hi*' 
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SECTION B-6 

FIND Process 


FIND is a process that finds a specified file when only the file name (or 
only a portion of the file name) is known. 

The file name specifications may have embedded question marks (?) to 
designate universal match (“don’t care”) characters. In addition, the file 
name may be specified with leading and or trailing asterisks which act as 
wildcards. Asterisks do not function as embedded wildcards. 

Here are some examples of specification strings and the files they would 
find: 

ju?t— to find all files beginning with ju and ending with t. For example, 

JUAT, JUBT. 

just* —to find all files beginning with just. For example, justify, jus¬ 
tice. 

*just —to find all files ending with just. For example, just, adjust, 
ojust. 


*just* to find all files containing just no matter where it appears in the 
file name. For example justify, adjuster, 
find can be run in one of two ways. 

If a parameter string is supplied, the program looks for the file as specified 
in the parameter string and then stops (Figure B-6.1). 


;find header 
$SYSTEM 

$SYSTEM.EDITOR.HEADER 


Figure B-6.1. Using find with a Parameter String. 


If no parameter string is supplied, the program prompts for file specifica¬ 
tions until you enter ireturni or Ictrli 0 (Figure B-6.2). 


; find 

File to look for: header 
$SYSTEM 

$SYSTEM.EDITOR.HEADER 
File to look for: EOF! 


Figure B-6.2. Using find without a Parameter String. 


FIND Error Messages 

The following messages may be given while you are using find. Most 
message occur immediately following the command entry which generated 
the error. 


“case statement index out of range!”—Contact your Sll System Engineer. 
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“Everything matches!”—You may have specified a string like 

“Fatal i/o error in [filename]”—There has been a hardwaip failure, the disk 
drive is not working properly, the file is full, etc. 

“Line too long”—Recheck the syntax of the command line. 


“No startup message found!”— find did not receive the startup message it 
expected from the Sll Command Interpreter. Try executing the pro¬ 
gram again. If you get this message a second time, contact your Sll 
System Engineer. 

“open failed for [filename]”— Either the file does not exist or you do not 
have the authority to access it. 




System Managers Manual 


PERCENT 


SECTION B-7 


PERCENT 

Report Text Storage In Use 

PERCENT is non-interactive process which searches text files and 
reports the percentage of text file storage currently in use. System/55 
stores bytes of information, on pages, and stores pages in extents. The 
extents comprise a data file. 


How Text File Storage is Used 

Text file records are linked together in a chain. The front chain is a list of 
records immediately available for storing stories and ads. The rear chain 
contains all oops copies which have been created. Text storage areas 
which have never been used are called “virgin free records”. 


Text file storage space is used in the following order: front chain; rear 
chain, if old enough; virgin free records. If all of this storage space is used, 
the system begins to write over the rear chain regardless of story age. 


When a story is filed, the system first searches the front chain for a place 
to store it. If no records are available there, the system tries to store it in 
the rear chain. When searching the rear chain the system looks for the 
oldest story. If it is old enough to be purged (usually 24 hours), the new 
take is put in its place. 


If the front chain is full and nothing in the rear chain is old enough to 
purge, the system begins using virgin free records. As these records are 
filled, the system automatically attempts allocation of another extent. 

When all extents have been allocated, and there are no virgin free 
records remaining, the system begins writing over oops copies regardless 
of their age. If this area of text storage is exhausted the system can no 
longer store new takes; reporters and ad takers can no longer file their 
work. When this happens, newspaper operations come to a halt. 

Text file storage availability changes constantly. It may approach capac¬ 
ity during periods of high system activity as reporters begin filing stories, 
salespeople take ads, and wire service activity increases. Later, when 
deadlines have passed and the paper has gone to press, storage availabil¬ 
ity increases as input frequency declines and the system purges old takes. 

percent allows you to monitor these changes and provides valuable 
information which can be used to manage text file storage most effectively. 


Running PERCENT 

Enter Sll Command Interpreter and enter «percent» at the semicolon 
prompt. There are no commands or parameters. A typical report is illustrat¬ 
ed in Figure B-7.1. 
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;percent 

Text file information for Editorial 
Text file $DATA.PDQB.ETEXTF is 60 % full 
0 records are free in front chain 
4,732 records are free in rear chain 
30,412 records are virgin free records 
54,855 records are in use out of 89,999 

Text file information for Classified 
Text file $DATA1.PDQB.CTEXTF is 74 % full 
0 records are free in front chain 
22,160 records are free in rear chain 
4,682 records are virgin free records 
79,422 records are in use out of 106,264 


Figure B-7.1. percent Listing of Text File Record Availability. 


In Figure B-7.1, there are no records remaining in the front chain, and 
the system is writing over old oops copies. The percent report in Figure 
B-7.2 shows a text file approaching capacity (assuming that all extents 
have been allocated). 


Text file information for Editorial 
Text file $DATA.PDQB.ETEXTF is 92 % full. 

0 records are free in front chain. 

7,198 records are free in rear chain. 

0 records are virgin free records. 

82,801 records are in use out of 89,999 

Text file information for Classified 
Text file $DATA1.PDQB.CTEXTF is 99 % full. 

0 records are free in front chain. 

1,061 records are free in rear chain. 

0 records are virgin free records. 

105,203 records are in use out of 106,264 


Figure B-7.2. percent Listing of Text File Record Availability. 


If percent reports that text file storage is nearing capacity, you can 
spike stories or change story expiration time to permit automatic purging to 
begin. If percent consistently shows text file usage approaching 100 
percent during periods of high system activity, additional text storage may 
be needed. 
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SECTION B-8 

DISKINFO Process 


This is an unsupported Tandem product. It is not maintained by Sll. 

DISKINFO is a process that provides disk space information for a speci¬ 
fied volume and subvolume or all subvolumes of a specified volume. 

The figures in this section show the information displayed by diskinfo 
as it appears on a Coyote vdt. When displayed on an et/960 some lines of 
the display may wrap. 


Running DISKINFO 

To list the disk space information for your default subvolume, enter 
«diskinfo» at the semicolon prompt, followed by (return]. 


;diskinfo 




SUBVOLUME 

PAGES BYTES 

FILES 

82 OCT 07, 16:26:59 

$SYSTEM.SYSTEM 

3341 6842368 

179 


TOTAL PAGES 

3341 



TOTAL BYTES 

6842368 



TOTAL FILES 

179 




Figure B-8.1. diskinfo Listing for Default Subvolume. 



To list disk space information for a specific volume and subvolume, 
enter the volume and subvolume name as in Figure B-8.2 below. 


;disk i nfo $data.e ditor 

SUBVOLUME PAGES BYTES FILES 


$DATA.EDITOR 


15000 30720000 5 


82 OCT 07, 17:32:21 


TOTAL PAGES 15000 
TOTAL BYTES 30720000 
TOTAL FILES 5 


Figure B-8.2. diskinfo Listing for $data.editor. 
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To list disk space information for all subvolumes on a particular volume, 
enter the volume name followed by an asterisk, which acts as a wild card 
(Figure B-8.3). 


;diskinfo $system.* 




SUBVOLUME 

PAGES 

BYTES 

FILES 

82 OCT 07, 17:43:17 

$SYSTEM.CCONTROL 

990 

2027520 

34 


$SYSTEM. CDUMP 

105 

215040 

8 


SSYSTEM.DICT 

1 

2048 

1 


$SYSTEM.ECONTROL 

1092 

2236416 

35 


$SYSTEM.FGEN 

436 

892928 

14 


$SYSTEM.FMOD 

70 

143360 

7 


$SYSTEM.SPEDIT 

118 

241664 

4 


$SYSTEM. STYL 

187 

382976 

17 


$SYSTEM.VPUTGET 

287 

587776 

10 _ 


TOTAL PAGES 

46491 




TOTAL BYTES 

95213568 




TOTAL FILES 

1840 





Figure B-8.3. Representation of Listing of all Subvolumes on Volume $system. 


At the end of the listing of all subvolumes on a specified volume, the 
total pages, bytes, and files is given. You may interrupt the listing of 
subvolumes at any time by pressing IcmdI . The total pages, bytes, and 
files for the subvolumes listed up to that point is displayed. 


«♦ 


■k: 
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SECTION B-9 

READYQ 


READYQ displays the program file names of the processes waiting to 
be run for the processor on which it is executed. A job is in the ready 
queue if: 

1. It is running, 

2. it is ready to run but is waiting for the cpu, or 

3. it is waiting for a page to be paged in. 

Processes waiting for i/o or waiting for interprocess communications are 
not in the ready queue. Normally there are very few processes in the ready 
queue. 


Running READYQ 

READYQ can be executed from the SI I Command Interpreter. At the 
semicolon prompt enter «readyq» followed by the cpu for which you wish 
to see statistics displayed (Figure B-9.1). 

If you do not specify the cpu, readyq will run in the first available cpu. 


;readyq /cpu 0/ 




Pri LCB 

Name 

Program 

File Name 

00,037 170 005 

$ISPL 

$SYSTEM 

.SYSTEM . 

SPOOL 

00,023 170 006 

$SPLS 

$SYSTEM 

.SYSTEM . 

SPOOL 

00,032 146 001 

$EXOR 

$DATA 

. M68 

M68LINK 

00,082 121 002 


SSYSTEM 

.SYSTEM . 

TAL 

00,066 120 003 

$INTK 

$SYSTEM 

. SII 

INTAKE 


Finure R-9 1 Ramnlp rfadyo I istinn 


Note that processes are in order by priority in the ready queue. A 
process which is hogging the cpu should be first or second in the queue. 
Ordinarily it is a good idea to run readyq two or three times to determine 
which process is consistently monopolizing cpu time. System processes, 
for example, the memory manager, disk processes, and so on, all run at 
priorities above 200. Since readyq runs at less than 200, no system 
processes can ever be caught in the ready queue by readyq. User pro¬ 
grams running at a higher priority than readyq will be listed only if they are 
waiting because of a page fault. 
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SECTION C-1 

REQUEST 


REQUEST is a utility which sends parameters to Sll software. The 
parameters have a different effect depending on the program which re¬ 
ceives them. 


For the purposes of example, typical program names are used in the 
table below to refer to various process types: $zeus (super), $egod and 
$cgod (god), $dna (download), efio (fio), and $A504 (vcontrol). The 
program names are not fixed, and may be different on your system. 



Table C-1.1 



Process Requests 

PROCESS 

REQUEST 

RESULT 

$ZEUS 

11 

Starts downed processes 
which are descendents of 

$ZEUS 

$ZEUS 

i2,“\node” 

Downs all processes which 
are descendents of Szeus 

$ZEUS 

12,“c” 

Downs all processes in Clas¬ 
sified which are descendents 
of Szeus. 

$ZEUS 

12,“E” 

Downs all processes in Edito¬ 
rial which are descendents of 
Szeus. 

$EGOD 

11 

Starts downed processes 
which are descendents of 
Segod. 

$EGOD 

n 2, io, d (story #) 

Deletes given take from re¬ 
questor’s queue. 

$CGOD 

n 

Starts downed processes 
which are descendents of 
Scgod. 

$CGOD 

n 2, io, d (story #) 

Deletes given take from re¬ 
questor’s queue. 

$DNA 

io“$ax” 

Sends a message to vcu Sax 
“ vcu will be downloaded 
soon.” 

$DNA 

n“Sax" 

Downloads $ax. 

$DNA 

i2“$ax” 

Downloads all Coyotes on 

Sax. 

$EFIO 

19 

efio closes its files. 

$A504 

-20 

Start the terminal $A504 is 
running. This request can be 
made to any vcontrol pro¬ 
cess. 
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Executing the Process 


request can be executed from SI I Command Interpreter. At the semi¬ 
colon prompt enter«request” followed by the process name and Ireturni . 


request will return its process number and a question mark prompt. At the 
question mark prompt, enter the desired parameters followed bv 
Ireturni . 


request will again return its process number so that you may enter more 
parameters if you wish. If you do not want to enter more parameters, respond 
to the prompt with IctrlI [yJ . request will then prompt for another process 
name. If you do not want to request another process, respond to the aues- 
tion mark with IctrlI [y1. 

Figure C-1.1, below, illustrates the format for making a request to a single 
process. 


;request {process name) 

00,023; ? (param), (param), etc. 
00,023; ? (eof) 

00,023; Process; ? (eof) 


Figure C-1.1. Format for Executing a request to a Process. 


Figure C-1.2, below, illustrates a request to download a vcu. 




Figure C-1 .2. Sample request to Download vcu $ai . 


REQUEST Error Messages 

The following messages may be given while you are using request. 
Most messages occur immediately following the command entry which 
generated the error. 

“Backup can’t open”—The request process cannot talk to the backup. 

“Backup cpu failed”—The backup cpu has failed. 

“Backup running”—The backup process is running. 

“Backup process abended”—The backup process has stopped due to an 
error. 

“Backup process stopped”—The backup process has stopped due to an 
error. 


Can t checkopen [filename]”—There has been a hardware error: the file 
is full, the disk drive is not working properly, etc.. 

Can t checkpoint to backup”—There has been a hardware error of some 
sort: the file is full, the disk drive is not working properly, etc. 


Can t open [filename]”—Either the file does not exist or you do not have 
the authority to access it. 
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“i/o error from [filename]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 

“Illegal device”— request allows parameters to be passed only to pro¬ 
cesses. 


“Invalid input string”—There is an error in the command syntax. Recheck 
your entries on the command line. 

“Invalid parameter to command”—There is an error in the command syn¬ 
tax. Recheck your entries on the command line. 

“Invalid server process name”—You may have entered the process name 
incorrectly. Recheck your entries. 

“Must be run interactively”—The in and out files for the request process 
must be the same. 

“No backup created”—No backup for the request process has been 
created. 


“No startup message found”— request did not receive the startup mes¬ 
sage it expected from the Sll Command Interpreter. Try executing 
request again. If you get this message a second time, contact your 
Sll System Engineer. 

“Primary cpu failed”—The cpu has failed for some reason. 

“Primary process abended”—The primary process has stopped due to an 
error. 


“Primary process stopped”—The primary process has stopped due to an 
error. 

“Returned from checkmonitor”— There has been a software error: the 
primary process has failed; the backup process is failing. Try again. If 
you get this error a second time contact your Sll System Engineer. 

“Server”—Errors have been received from the server process. 

“Unknown command”—The characters of the first word you have typed on 
the command line do not match those of a request command. 
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SECTION C-2 

TAPE 

Tape is an interactive process used to save stories from disk to magnet¬ 
ic tape for backup purposes. The tapes are then removed for storage and 
possible recovery later. Because of the significance attached to long-term 
storage, extreme care must be taken to ensure both proper data transfer to 
tape and proper storage of the reel once filled. 

Magnetic Tape Organization 

A magnetic tape is logically divided into several areas (see Figure 
C-2.1). Areas where takes are stored are called sets. While each set is 
logically separated and each system is unique, it should be noted that two 
consecutive tape sets may contain stories saved from different systems. 
Each set begins with some identifying information such as its parent 
system, the date and time it was written, the set name and so forth. This 
identifying information is followed by the story information. 



□ 


Figure C-2.1 Magnetic Tape Organization. 

Help Command 

TAPE has a Help command. To use it, start the process, and enter 
«help» (see “Running tape Interactively” later in this section). All of the 
available commands and a brief description of each will be listed (Figure 
C-2.2). 
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♦help 


FC 

HELP (command) 

VERSION 

EXIT (or EOF!) 

QUIET 

INSERT 

AUDIT 

BLITZ 

REWIND 

SCAN tapeset 

RSCAN tapeset 

EOT 

SYSTEM 

TAPESET 

PATH path [key] 

CLEAR 

SELECT 

REJECT 

SAVE 

RESTART [story #] 

RESTORE 

LIST 


Print long command descriptions 
Print version information 
Terminate execution of process 
Don't list stories saved/restored 
Insert stories in header file 
Save/restore audit copies 
Set blitz (fast restore) mode 
Rewind the tape 
Scan forward for a tapeset 
Scan backwards for a tapeset 
Skip to end of the tape 
Specify the SII system to use 
Specify the tapeset name 
Specify positioning information 
Clear SELECT/REJECT conditions 
Set a selection condition 
Set rejection condition 
Save stories to tape 
j|pecify restart story number 
Restore stories from tape 
List the contents of a tape 


Standard COMINT fix command 



Figure C-2.2. TAPE Help Command. 


To display a more detailed description of a specific command enter 
«help (command name). 


Exiting TAPE 



You can exit tape at any time by pressing IctrlI 0 or entering «exit» in 
response to the process prompt. 


Available Commands 


SYSTEM 

The system command specifies the system from which stories are to be 
saved or restored: 


♦system e 


TAPESET 

The tapeset command specifies the name of the next set of saved or 
restored stories. The name of the set is written to tape along with the 
saved stories. When restore is run, the tape is searched, from the current 
tape position, for the specified tapeset. For example: 


♦tapeset wire 


A tapeset must start on the current tape, even though it may be split 
across several tapes. 

AUDIT 


The audit command causes all audit copies to be saved 



when tape is run. 


or restored 
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INSERT 


Normally, tape makes oops and audit copies; if the insert command is 
given, all stories are inserted and existing stories are not changed. If the 
insert command is not given, the current copy becomes an oops or audit 
copy. 


LIST 

The list command lists the contents of all sets on the tape. This 
command will continue listing a set split across several tapes. 


PATH 


The path command specifies positioning information used to select a 
portion of the header file for saving. The path is the familiar two letter 
mnemonic used with directory commands. If no path is supplied, the entire 
header file is scanned--which can take a considerable amount of time. The 
optional key may only be used with the specific paths listed below. The 
format of the key varies from path to path, as is indicated below: 


ba basket name 

de desk name 

au author’s name 

to topic 

ke keyword 

sn 'story name' , compare length 

ex expiration date 


For instance, the sn path may be used as follows: 

* SN "c las s"j 5 


where 5 is the number of leading characters the process will compare 
when selecting story names (the position of the asterisk if this were a 
directory prompt). This particular example selects all stories whose first 5 
letters are “class” (classified, class dump, and so on). 


QUIET 

The quiet command prevents the process from listing each story as it is 
saved or restored. This command is used primarily when tape is run 
interactively from a vdt. 


SELECT and REJECT 

The reject command specifies a condition which, if true for a story, 
causes it to be skipped, and not saved or restored. 

The select command specifies a condition which, if true for a story, 
causes the story to be saved or restored as appropriate. 

Up to 10 different select/reject statements may be in effect at one 
time. If none of the select/reject conditions is found to be true, the 
information garnered from the previous test is used to determine story 
selection or rejection. If the last test indicated a select, stories failing that 
test will be rejected, and vice versa. 

A condition is defined as any number of relations strung together with 
either and or or. A relation is either of two things: 

1. A header q-field name, followed by a relational operator, followed by a 

constant value; or 
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2. a complete condition enclosed in parentheses. 
The signed relational operators are: 


< 

> 

< = 
> = 
<> 


Values of the operands are equal 
Left value is less than right value 
Left value is greater than right value 
Left value is less than or equal to right value 
Left value is greater than or equal to right value 
Values are not equal 

The unsigned relational operators are: 


> 

> = 
< = 
< 


greater than 
greater than or equal to 
less than or equal to 
less than 


Here are some sample expressions: 

SELECT parbon send = "AP" or carbon'send = "SA" 
REJECT length < 2 

REJECT release status = "R" and filnfstatus = "F" 


Dates may be specified in the form mm/dd/yy or as today, tomorrow, 
yesterday, tuesday, and so on. Dates specified in this fashion may be 
further modified by adding or subtracting a number of days for example: 

SELECT entry'date >= today - 3 
SELECT last~date >= yesterday -2 


Times may be specified in the form hh:mm:ss or as “now +/- n” where 
‘n ’ represents a number of hours. To select stories entered since one hour 
ago: 


SELECT entry^time >= now - 1 


CLEAR 

The clear command eliminates the story selection/rejection conditions 
previously set by the select and reject commands. 


Tape Control Commands 


REWIND 

The rewind command causes the process to rewind the tape. If the 
process is run interactively (from a terminal), the command merely starts 
the rewind. If the process is not being run interactively, it starts the rewind 
and waits. When rewind is complete, command processing begins anew. 

EOT 


The eot command causes the process to search for the end of the tape. 

SCAN 

The scan command scans forward through the taoe for thp snorifiow 
set. Each skipped set is listed. Ifthe selected L « „T ° ® SpeC,fied 

an error message. ected set is not found, tape returns 
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RSCAN 

The rscan command is similar to scan. This command scans backward 
through the tape for the specified set. It lists all skipped sets and returns 
appropriate error messages for sets that are not found. 

SAVE 

The save command begins saving stories to tape. Unless the quiet 
command has been given, each saved story will be listed on the printer 
(Figure C-2.3). 


Start of tapeset ’sports’, HC system: e 
Tape written on 5/12/82 at 02:00:41 (HC) 


Story 

Number 

Story 

Name 

Basket 

Desk 

Author 

Reel 

#1132 

49ers 

SPORTS 

SPORTS 

FRANK 

1 

#1463 

Raiders 

SPORTS 

SPORTS 

AL 

1 

#1628 

Lakers 

SPORTS 

SPORTS 

JON 

1 

#1795 

LPGA 

SPORTS 

SPORTS 

ANN 

1 

#1954 

Track 

SPORTS 

SPORTS 

BOB 

1 


94 stories in tapeset. 

Figure C-2.3. Story Listing for a Single Tapeset. 


RESTORE 

The restore command begins restoring stories from tape. It searches 
forward on the tape for the current set. If the set is not found on the tape, 
an error is given. The process will not request the next sequential reel 
while searching for the set. Once the correct set is found, the command 
requests the next reel if the set is split across several reels of tape. 

BLITZ 

The blitz command restores large numbers of stories from a tape at a 
single time, as fast as possible. It does so by locking the entire header file 
before starting the restore. This prevents all access to the header file by 
other processes. While blitz is working, users cannot obtain directories or 
call up stories for editing. Users with stories on their screens will be able to 
continue editing but will be unable to file the take until restore is com¬ 
plete. Wire collection is affected the same way. 

Running TAPE Interactively 

Entering «tape» in response to the command interpreter prompt does 
not start the process. It only logs the instructions for doing so and supplies 
the Sll Command Interpreter prompt again (Figure C-2.4). 
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; tape 

TAPE is a program to 

write SII stories to magnetic 

tape for storage and 

later recovery. 

: tape /in (commands), 

out (list)/ (tape), (config) 

Where: (commands) 

Source for commands 

(list) 

Where to list results 

(tape) 

The device we should do I/O to 

(conf ig) 

The configuration file name 

The program prompts for commands. The HELP command is particular¬ 
ly useful. 

» 


Figure C-2.4. tape Startup Instructions. 


To start the process from Sll Command Interpreter, enter the parame¬ 
ters and press IreturnI (Figure C-2.5). 


TAPE -- SII tape utility program 5/19/82 14:40 

; tape $tapeonf igurat ion f i 1 e name) 


Figure C-2.5. Starting the tape Process. 

When you have supplied the correct run parameters, the process 
prompt (*), an asterisk, is displayed, and the name of the process is given 
at the top of the screen as long as the process is running. To begin 
specifying the data which is to be saved to tape, enter the commands at 
the asterisk prompt (Figure C-2.6). 


♦system e 

*-.tapesetedi tor i a 1 
*-rej_ect : __desk*name__ == "wire" 
* save 


Figure C-2.6. Running tape Interactively. 




Running TAPE from a Data Take 

The tape process can also be run from a data take. A typical data take 
for running tape, showing the manner in which the parameters are to be 
entered, is illustrated in Figure C-2.7. Once the take has been set up 
correctly, you may use it to run tape by outputting it ( [cmd! Jof). When 
tape is run in this fashion, messages generated by the process are not 
logged on the terminal. They are sent to the out file specified in the startup 
parameters. 


Story daily backup topic 

Basket PRODUCTION Desk 
Output DATA _ ( TANDEM 


J 


Keyword _ 

Author RICK 


tape/out (f ilename)/(device), (conf iguration file) 

system e 

tapeset (name) 

select/reject statements 

save 

Figure C-2.7. Data Take to Run tape. 
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Suggestions for Use 


Three recommended methods of file backup are described below. Each 
method dumps a different number of text files each time tape is run, and 
requires a different number of tape sets. Each method uses a seven day 
cycle, with daily file backups. Transfer of files to tape is most conveniently 
made during periods of low system activity when it will cause only minimal 
disruption of normal activity. This also ensures that files are as nearly static 
as they ever become. 

Daily Transfer of all Files to Tape 

All text files in the system are dumped to tape daily. This method has the 
advantage of requiring only two tape sets to maintain complete file curren¬ 
cy. And, one tape set restores all files. On the other hand, the daily 
procedure is extremely time consuming. The format for a typical data take 
to perform this type of save is illustrated in Figure C-2.8. 


Story daily backup Topic _ Keyword _ 

Basket PRODUCTION Desk _ Author RICK 

Output DATA ( TANDEM ) 


tape/out (f ilename)/(device), (configuration file) 
system e 
tapeset (name) 
save 


Figure C-2.8. Data Take to Save All Files to Tape. 
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Daily Transfer of all Changed Files 


All files in the system are dumped to tape on the first day of the cycle. 
Then, on each succeeding day, only those files which are new or have 
been modified since the previous tape write are dumped. For example, if 
the cycle starts on Sunday, all files are saved. On Monday, all files 
changed on Monday are saved, and so on. This method is less time 
consuming than a daily dump of all files, since only those files which have 
been modified or entered that day are written to tape. However, this 
method requires a new tape set for each day of the cycle, plus one, even 
though sets containing partial backups are smaller than those used for a 
full backup. Writing from tape back to disk is slower and more complex 
with this method and could require up to seven tape sets. 


This method lends itself to the use of a data take or several data takes. If 
tape is run at the same time each day early in the morning for example, 
one data take can be used to save all stories entered or changed on the 
preceding day. Use a convenient identifier for the tapeset, such as the date 
on which the save was made (Figure C-2.9). 


Story daily backup Topic _ Keyword _ 

Basket PRODUCTION Desk _ Author RICK 

Output DATA ( TANDEM ) 

tape/out (f ilename)/(device), (conf iguration file) 

system e 

tapeset 5/05/82 

select entry'date = yesterday 

select last'date = yesterday 

save 


Figure C-2.9. Data Take to Save All Stories Entered or Changed “Yesterday”. 
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If you wish to be more specific, in saving stories you can use se¬ 
lect/reject statements to select stories which have been entered or 
changed since the exact date and time that tape was last run. For exam¬ 
ple, if tape was last run to save stories at 2:05 am on 5/05/82 the data take 
to save all stories entered or changed since that time might look like Figure 
C-2.10. 


Story daily backup Topic _ Keyword 

Basket PRODUCTION Desk _ Author RICK 

Output DATA ( TANDEM ) 


tape/out (filename)/(device), (configuration file) 
system e 

tapeset (name)select entry'date >= 5/05/82 

select entry^time >= 02:05 

select last'date >= 5/05/82 

select last'time >= 02:05 

save 


Figure C-2.10. Data Take to Save all Stories Entered or Changed Since 5/05/82 at 2:05 am. 
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Daily Transfer of Files Changed Since Start of Cycle 

All files in the system are dumped on the first day of the cycle. On 
succeeding days, all files created or modified since the first day of the 
cycle are transferred to tape. For example if the cycle begins on Sunday, 
all files would be saved on that day. On Monday, all files changed since 
Sunday would be saved; on Tuesday all files changed since Sunday would 
be saved--and so on for each succeeding day. This method offers time 
saving over both of the previously described methods since the only files 
which are written to tape each day are those which have been modified or 
entered since the first day of the cycle. And, only two tapesets are needed 
to restore all files (Figure C-2.11). 


Story daily backup Topic 
Basket PRODUCTION Desk 
Output DATA ( TANDEM ) 


Keyword _ 

Author RICK 


tape/out (f ilename)/(device), (configuration file) 

system e 
tapeset (name) 

select entry'date > 5/05/82 
select last'date > 5/05/85 
save 


Figure C-2.11. Data Take to Save All Stories Entered or Changed Since the Start of the Cycle. 
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Tape Security 


Once files have been transferred to tape, there is still the question of 
protecting the tapes from possible damage or misuse. Ideally, tapes 
should be stored in a fire proof vault some distance from the newspaper. 


TAPE Error Messages 

The following messages may be given while you are using tape. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 

“Badly formatted date”— tape cannot decipher the date as you have en¬ 
tered it. 


“Badly formatted number”— tape cannot decipher the number you have 
entered (for length comparison in the path sn command for exam¬ 
ple). 

“Can’t open a file”—Either the file does not exist or you do not have the 
authority to access it. 


“Case statement error”—There has been a program error. Notify your 
System Manager. 

“File system i/o error”—There has been a hardware failure. Notify your 
System Manager. 

“I can’t handle bit fields”—You tried to select or reject a story based on a 
Q-field which is a single bit flag, tape does not allow this. 

“I don’t understand this”—A command or parameter is undecipherable as 
you have entered it. 


“Illegal command”— tape cannot decipher the command as you have 
entered it. 


“Illegal syntax”—The syntax of a select or reject command is incorrect. 

“Invalid parameter string”—You have entered the tape startup parameters 
incorrectly. 

“Invalid time specified”—You have specified an invalid time in a select or 
reject statement. 


“Missing leading quote”—A string constant being compared to a Q-field in 
a select or reject statement must be enclosed in quotes. For 
example filnTstatus = "f". 


“Missing right parenthesis”— A complete condition in a select or reject 
statement must be enclosed in parentheses. 

“Missing trailing quote”—A string constant being compared to Q-field in a 
select or reject statement must be enclosed in opening quotes. For 
example filrTfstatus = "f". 


“Must be a tape device”—The device specified in the tape startup parame¬ 
ters is not a tape drive. 


“No bit arrays, please”—You tried to select or reject a story based on a 
Q-field which is a single bit flag, tape does not allow this. 


“No key with that path”—You have specified a path for which a key is not 
allowed. 
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“No startup message found”— tape did not receive a startup message. Try 
again. 

“No story header found”— tape could not find a story header on the tape 
you are trying to restore. This may indicate a bad tape. 

“No such Q-field name”—The process does not recognize the Q-field 
name you have specified in a select or reject statement. 

“No system specified”—You have not specified a system with the system 
command. 

“No tapeset specified”—The name of the set of stories to be saved or 
restored must be specified with the tapeset command before saving 
or restoring can commence. 

“Not a unique abbreviation”—The abbreviation you entered for a com¬ 
mand is not unique. Enter it with more characters. 

“Quoted string is too long”—You entered a string constant in a select or 
reject statement which is longer than the Q-field to which it is being 
compared. 

“Reel isn’t number 1”—You are attempting to start restore in the middle of 
a set of reels. The process allows you to do this; this message is 
intended only to inform you that it is happening. 

“Restore didn’t find it”—The specified tapeset was not found. 

“System does not exist”—The system specified in the system command 
does not exist. 

“Tape label is bad”—The tape can’t be read or it was not written by the 
tape process. 

“Too many select/reject” —A maximum of 10 select/reject state¬ 
ments is allowed. 
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SECTION C-3 

VUP 

VDT Utility Process 


vup is a general-purpose process with six available functions: 

stop— Stops a vdt control process (econtrol [editorial], ccontrol 
[classified]). This function places the vdt in a signed-off state (the 
process is dormant). The vdt may not be signed-on again until the 
process is restarted with the Start function. 

kill —Kills a vdt control process, removing it entirely from cpu memory. 
The only reason for doing this is to load a new, updated version of the 
process. 

start —Starts a vdt control process (following system maintenance) that 
was stopped with the Stop function. 

send —Sends a message to a vdt control process (a physical vdt). The 
message is displayed on the status line. 

signon —Instructs the vdt process to sign on the user found in the vup 
sign-on information file (vup info). 


execute —Instructs the vdt process to execute a gdk. The gdk and the 
name of its associated glossary are found in the vup sign-on informa¬ 
tion file (vup info). 

Each of the six vup functions may be performed for: 


1. a group of processes (a vdt stop group, representing physical termi¬ 
nals); 


2. a single process; 

3. all processes running on a specified cpu; 

4. all processes running on a logical system; 

5. for all processes with a specified program file name; or 

6. all processes running in wrong cpu. (This is a group [icpu] of vdt 
processes which are supposed to be running in one processor, but are 
in fact running in another processor. It is used for load balancing after a 
processor is reloaded and is being brought back into the system.) 


Defining VDT Stop Groups 


Normally it is most convenient to perform vup functions by referencing a 
group of processes which are running against specific vdts in specific 
locations. The process in the host computer is said to be running “against” 
the terminal, meaning that the process supplies the terminal with its “intelli¬ 
gence” for data base interaction. 


vdt groups are defined by creating a record specifying each pro¬ 
cess/group relationship. The record uses the structure «vdt a stop». (See 
Index of Record Structures [S55-007] for instructions on how to determine 
the file name to use for forms and lists.) 
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The record form looks like this: 

Process name _ Group name 


Each process name must be defined in the configuration file. Here is a 
typical process name: $A4i2. 

A process name begins with a dollar sign ($). The first two characters 
following the dollar sign--a letter (a-z) and a number (0-9)--represent the 
Video Control Unit (vcu, controlling et/960 vdts) or Terminal Control Unit 
(tcu, controlling Coyote vdts). This scheme permits up to 26 alphabetic 
groups with up to 10 control units per group. The last two digits represent 
the board position in the control unit. Therefore, the above process is 
running against terminal number 12 in control unit A4. This name is always 
used to reference the process ($A4i2) running against the physical termi¬ 
nal ($A4.#Ti2), both in the configuration file and by vup. 

You assign the group name. There may be as many groups as you like, 
and a process may belong to any number of groups. It is most efficient to 
create new stop group records from an index. Point the cursor at an 
existing record and enter Icmdi [j] 0. A blank record of the same type will 
be displayed. You must supply both the process name and the group 
name. Consider defining vdt stop groups: 

1. By control unit. This is required for successful operation. Define stop 
groups by the vcu or tcu to which the terminals are connected, naming 
the control units as they are specified in the process names--Ai, A2, A3, 
etc. (a System/55 convention). This will enable you to stop, start, and 
send messages to all terminals on a single vcu or tcu. 

2. By physical VCU or TCU location. If the control units are divided into 
several locations in the newspaper, perhaps outside of the main com¬ 
puter room, you will want to define the units in each location as a group. 
If your system supports one or more remote vcus or tcus at a bureau 
location, that bureau would be a group. Being able to stop these units 
quickly will enable you to perform swift maintenance on them with a 
minimum of discomfort to users. 

3. By physical VDT location. This is less often a need. If construction or 
other building maintenance is being performed in an area of the news¬ 
paper which would prevent users, for electrical or other reasons, from 
safely continuing with their work, you may wish to define those vdts as 
a group to be able to stop them easily and quickly. 

Note that it is unnecessary to define groups by vdt application-classi¬ 
fied or editorial-since vup also provides the means of stopping vdts by 
system or program file name. Moreover, any vdt may be signed-on to any 
system and a vcu or tcu may be split between editorial and classified. A 
list of vdt stop records should be defined for your system so you may list 
them on a vdt or on hardcopy. The list is sorted first by group name, then 
by process name. 

Executing VUP 

To execute vup start Sll Command Interpreter and enter «vup» followed 
by the startup parameters and the desired function (Figure C-3.1). 
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; vup 

VUP /IN (configuration file name), OUT (list file name)/ 

[(delay)] 

(function) 

(GROUP (name)) (PROC (name)) (CPU (number)) 

(SYSTEM (id)) (PROG (program filename)) 

((a message)) 

Figure C-3.1. Starting vup. 

It is necessary to specify the configuration file name as the in file only if 
you are executing the process from a terminal not manufactured by SI I (a 
terminal not running under a vcontrol process), and the out list file name 
is required only if you wish messages from the process to be printed on a 
device other than the executing vdt. 

Under normal conditions, therefore, these parameters are not required. 

vup is executed by typing a function keyword (send, stop, kill, start, 
signon, or execute), followed by a modifier keyword (group, proc, cpu, 
system prog or icpu), followed by a parameter appropriate to the modifi¬ 
er (name, number, i.d.), followed, as appropriate, by a message. When 
«vup» is entered in response to the Command Interpreter prompt with no 
parameters or with erroneous parameters, the process provides help as 
shown in Figures C-3.2 and C-3.3. 


VUP - VDT Utility Process; 6/09/82 13:17:59 
To run it: 

VUP /in (config file), out (list file)/ 

[(delay)] 

SEND, STOP, KILL, START, SIGNON,EXECUTE 
(GROUP (name)) (PROC (name)) (CPU (number)) 

(SYSTEM (id)) (PROG (program file name)) 

((a message)) 

The optional (delay) parameter specifies the number 
of seconds to delay between messages. Note that the PARENTHESES 
ARE REQUIRED, 
eyword ICPU. 

If SEND is specified and no message is entered, a canned 
message is sent to all VDTs informing the various users 
that their VDTs will be stopped shortly. 

If STOP is specified and a message is entered after the 
VDT process group name, that message is broadcast to all 
VDT control processes in the group, else a canned message 
is sent informing users that the VDT is stopped for 
system maintenance. 

The KILL function first stops the VDTs in the group, 
ensuring that no data is lost. 

The SIGNON function signs on the user(s) listed in the VUP 
information file under the process name(s) specified. 

If that user has a password, the sign-on fails, unknown to 
VUP. 


Figure C-3.2. Help Provided by the VUP Process (partial). 


C-3.3 







VUP 


System Manager^ Manual 


The EXECUTE function requests the VCONTROL process to execute 
the GDK found in the VUP info record associated with that 
process. 

This process does not guarantee that the function sent with the 
message is actually acted on by the control process; it 
only sends the message. 

Messages are displayed on the user's terminal, even if 
the user has executed the DO NOT DISTURB function, and 
are not entered into the user's message file. 


Figure C-3.3. Help Provided by the VUP Process (concluded). 


SEND Function 


This function is used for sending a message to [the users of] vdts, as 
represented by their process names. This, like all functions of vup, applies 
to a vdt in a specific location, not to the individual who may be signed-on 
to it. It should not be confused with the vcontrol Message command— 
Icmd| [m] —which sends messages to users and groups of users wherever 
they may be signed-on. 

The normal application of this function is to warn the users of vdts of 
impending system maintenance or of a new download of the vcu; i.e., an 
upcoming execution of the stop function: 

I YyP-.send group b4 ypTs will stop for rnaintenance l-l : 30 a. m. 


This function may also be used as desired for non-hardware-related pur¬ 
poses. In normal practice the message is addressed to a vdt stop group 
(see “Defining vdt Stop Groups,” above), in this case «b4». The message 
is displayed in the bright attribute on the status lines of all vdts in the 
group: 


VDTs will stop for maintenance 1-1:30 a.m. (^ORIGINATOR*) 

A confirmation is printed on the executing vdt: 


nnn processes in group, nnn messages sent 


The message plus the name of the sender (a user name, or «system» if 
the program is not being run from Sll Command Interpreter) must be able 
to fit on the status line of the vdt. The sender is always identified and, if 
necessary, the message is truncated to fit with the originator name in 64 
characters on an et/960. If the user has a maximum-length name of 12 
characters, the message may be 47 characters long. If the sender’s name 
is shorter, the message may be proportionately longer. 

A message may also be sent to an individual process: 

»y^P-.send proc $c2ll A new controller board is on its way. 


... or to all vdt control processes running on a specified cpu («send cpu 
3»), or assigned to a specified logical system («send system e»), or 
running on a particular program file name («send prog osii.econtrol»). This 
latter instance is applicable in advance of loading a new version of a vdt 
control program. 


If the send function is specified without a message, a standard “canned” 
message is sent: 
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VDTs will be stopped shortly (^ORIGINATOR*) 


This message is meant to save time when you are in a hurry. It is best to 
use the send function with your own message letting users know more 
specifically when vdts will be stopped. 

When vup is executed on a vdt running under a vcontrol process, 
that vdt’s process is the “ancestor” of the vup process. If the ancestor 
happens to be encompassed in the stop execution (as part of a group, 
cpu, system, or program file name), the ancestor process is excluded and 
is not stopped. 

To stop a group of terminals which includes your own, you 
may,therefore, execute vup from your own terminal with no difficulty. If, 
depending on the reason for, and duration of the stop, you need to stop 
your own vdt, that must be done from another terminal or a system typer. 

STOP Function 

vdts are stopped prior to system maintenance, most normal mainte¬ 
nance on a Video Control Unit such as the replacement of a board. After 
first filing a take or record displayed on a vdt (or stopping a utility process 
the user is running), the stop function suspends the specified control 
process in the host cpu until it is restarted with the start function. It 
follows the same format as the send function, and you may include an 
original message if desired, but the name of the originator is not broadcast 
as it is with the send function. 

If a message is not included, a canned message is broadcast to the 
specified processes: 


VDT stopped for system maintenance 


In addition to stopping vdts in groups, a single failing vdt (terminal or 
controller board) may be stopped until the problem can be corrected. You 
can also stop processes running on a cpu when that processor must be 
unavoidably put down for maintenance (extremely rare), and by system 
i.d. or by program file name when it is time to load new software. 

Note: When you stop a terminal or group of terminals, the terminal from 
which you execute the stop function is not stopped. 

Consideration for System Users 

When stopping vdts it is important to keep users informed of your 
intentions and to have respect for their work loads. When users know in 
advance that a vcu or a system is to be taken down at a particular time or 
for a specified period, they can adjust their schedules to get their work 
done. Try to avoid stoppages during heavy production periods. 

Plan maintenance periods in advance. If vdts must be stopped for more 
than 5 minutes, begin advising users with the send function some time in 
advance so that they can prepare for it. Repeat the message periodically: 
a user signed-on to a terminal ten minutes before the stoppage may not be 
the same person who was signed-on when you first sent the message. 
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KILL Function 


This function is rarely used. It is specified identically to the stop function 
(also with message capability) and it files all displayed data automatically 
so that none is lost. This function is required only to load a revised vdt 
control process that has been transmitted from SI I through the Network. 


The kill function, unlike stop, totally removes a process from cpu 
memory so it cannot be restarted without special steps being taken. This is 
not a function to be taken lightly; do not execute it without a thorough 
knowledge of the consequences. (Appropriate instructions for loading new 
software are given to the System Manager by Sll). 


START Function 

Following a stoppage initiated with the stop function, vdts are returned 
to a normal signed-off state with this function. The start function is 
executed identically to the other functions, except that a message may not 
be included. 

Note: When a vup function sending a message (send, stop or kill) is 
executed on a terminal not running under a vcontrol process 
(e.g., a console typer) the originator of the message, as printed on 
the recipient vdts is always “‘system*.” 

When executed through the Sll Command Interpreter the originator 
is always the name of the signed-on user—for example, “*gor- 
don*.” 


SIGNON and EXECUTE Functions 

The signon and execute functions use the vup info list and form. That 
form looks like this: 


Process 

Glossary 


User _ 

GDK __ Type 


signon instructs the vdt process to sign on the user found in the vup 
sign-on information file (vup info). 

execute instructs the vdt process to execute a gdk. The gdk and the 
name of its associated glossary are found in the vup sign-on information 
file (vup info). These functions are intended primarily for use during 
system staging. 


VUP Error Messages 

Note: Many of the error messages are followed by various standard 
system error numbers to make the error more specific. For the 
meanings of the error numbers, please consult the Tandem/16 
Software Pocket Reference Manual (Tandem Product No. 
ti 6/8031) or, in Sll Command Interpreter, enter “error” followed 
by the number to display an explanation. 


“Can’t communicate with (process name)”—The host cannot communi¬ 
cate with the named process. 

Can t find system description file in Config”—In connection with the sys¬ 
tem modifier, the file defining the system cannot be located in the 
Configuration file. 
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“Can’t find vdt stop file in Config”—You have specified for a function to be 
modified by a group name. However, the vdt Stop file containing the 
group definition records cannot be located in the Configuration file. 

“Can’t open config file, error nnn”—The configuration file cannot be 
opened. 

“Can’t open (file name), error nnn”—Either the file does not exist or you do 
not have the authority to access it. 

“Can’t open (program file name), error nnn”—Either the file does not exist 
or you do not have the authority to access it. 

“in file doesn’t look like config, error nnn”—The in file you’ve specified 
must be a valid configuration file. Even though the syntax of the file 
name may be correct, it doesn’t by its characteristics appear to be the 
right kind of file. 

“Info file entry not found for (process)”—No entry was found in the vup 
info file for the indicated process. After logging this message vup will 
automatically go on to the next process. 

“Invalid cpu number”—The cpu number specified with the cpu modifier 
does not exist or there are no vdt control processes running on that 
CPU. 

“Invalid function specified”—The function keyword you have specified is 
not valid. The four functions are: «send», «stop», «start» and 
«kill». They may not be abbreviated. 

“Invalid grouping specified”—The modifier keyword you have specified is 
not valid. The permitted modifiers are: «group», «proc», «cpu», 
«system » and «prog». They may not be abbreviated. 

“Invalid process name”—The process name specified with the «proc» 
modifier is not a legitimate process name as specified in the Configu¬ 
ration file, or one of the processes specified in a vdt Stop group 
record is invalid (It can’t be determined to be invalid until you attempt 
to use it with vup.) 

“Invalid program file name”—The program file name specified with the 
«prog» modifier does not conform to the proper filename syntax. 

“Invalid system, error nnn”—The system i.d. specified with the «system» 
modifier is invalid (probably a typo). 

“No one signed on to (process name)”—A vdt control process to which 
you’ve sent a message with the send function (not with stop or kill) 
does not have a signed-on user and therefore has not displayed the 
message. 

“(process name) is not stopped”—You have attempted to start a vdt 
control process that has never been stopped. 
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SECTION C-4 

MAINT Process 

MAINT is a utility process used to maintain baskets and desks. 

It is intended to be run any time the sorting order or sorting field of a 
basket or desk changes, maint is also used to fix basket or desk definition 
files after a change is made to a Q-field name. 

On the Advertising system, maint also cleans up blind box and tear 
sheet files by automatically deleting blind box and tear sheet records not 
associated with an ad (such situations may result from a system problem 
or operator error). It also deletes blind box reply records with no corre¬ 
sponding blind box record. 

The upperbound and lowerbound commands in maint set the range 
of blind box numbers for the system. The ccontrol process automatically 
assigns blind box numbers in this range as records are created. 

When maint processes stories, it recalculates offsets and sequencing 
information and writes new headers for all stories affected. Run after a 
Q-field change, maint simply updates offsets and sequencing information. 

MAINT User Identification 

The maint process logs on as user «maint», so program b (busy) will 
know who is updating data. If a story to be updated is locked, maint skips 
the story and sends a message informing the operator what is being done. 

Basket and Desk Sorting 

Basket and desk profiles contain the following line: 

Sorted (L,F,A, or R) _ by (field name) _ 

This is where the user specifies the order in which the contents of the 
basket or desk will be sorted. The four options are as follows: 

l— last in, first out (lifo) 

f— first in, first out (fifo) 

a —alphabetically by the specified field name 

r— in reverse alphabetical order by the specified field name 

If a basket or desk is to be sorted in alphabetical or reverse alphabetical 
order, the name of a Q-field by which to sort must be entered. Typical 
entries are story'name or topic. Refer to the sections on the header and 
cheader structures in the Index of Record Structures (S55-007) for list¬ 
ings of all available fields. 

The contents of baskets and desks are sorted as initially specified in the 
basket and desk profiles until the sort method is changed. All stories 
entered after the change will be sorted according to the new method, but 
the stories filed before the change will still be sorted according to the 
original method unless maint is run against the altered basket. 

If the user wants to have all the stories in the desk or basket sorted by 
the new method, maint should be run against the basket or desk to 
reorder all the stories. 
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Maintenance of Blind Box Records 


Command blind cleans up the blind box file by deleting bad blind box 
records. Before it can do so, however, the lower and upper limits of the 
blind box numbering range must be set, using the lowerbound and 
upperbound commands of the maint process. 

The lowerbound must be one or greater. 


Once these boundaries have been set, there is no reason to enter the 
commands again unless the blind box numbering range is to be changed. 
(These boundaries are permanent; they are not cleared or reset when you 
exit maint.) When the blind command is entered, maint begins reading 
through the blind box file at the lower boundary. If the lower boundary is 
not set, maint begins with record number one. 

The process checks each ad against the blind box numbers. If a box 
number does not match an ad number, the box is deleted, maint will also 
read through the blind box reply file, if one exists, and delete reply records 
if no corresponding valid blind box can be found. 


Running MAINT 

The maint process is run from Sll Command Interpreter: 

;maint econfig 


In this example, «e» is the system identifier (for instance, «e» for Editori¬ 
al or «c» for Classified), and «config» is the name of the configuration file. 
If you are running maint on an et/960 or Coyote terminal, you need not 
enter the system identifier and configuration file. 

You will be prompted with a «?». Accepted commands are: 

help (command). For a more complete discussion of information available 
through the help command, see “maint Help,” below. 

BASKET (BASKET NAME). 


desk (desk name). If a Q-field is changed in a basket or desk, or the order 
of story sorting is altered, maint will reorder it by rewriting the headers 
of stories in the basket or desk. Enter 

?BASKET (basket name) 
or 

?DESK (desk name) 


When you enter the basket or desk command, there is a slight pause 
while maint reorders the file. When the process has finished, maint 
informs you of the number of stories affected by the resorting: 

?n stories resorted 


fix [basket] or [desk]. If a structure is changed, thereby changing byte 
offsets and byte counts, maint will fix the baskets or desks by rewrit¬ 
ing record definitions. Enter 


?FIX BASKET 
or 

?FIX DESK 


class (class name). Reorders all active ads in the specified classification. 
After resorting, a message tells how many items were resorted. 
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lowerbound (lowest box number). See “Maintenance of Blind Box 
Records,” above. 

upperbound (highest box number). See “Maintenance of Blind Box 
Records,” above. 

dump. Deletes dump item records for ads which have been purged. 

stats. Deletes excess records in the class dump statistics files. 

tracking. Deletes records with nonexistent ad numbers in the ad tracking 
file. 

extract (fileset). Constructs and writes records to header extract files. 


exit. You may exit maint witn tnis command or with IctrlI 1 yI . 

MAINT Help 

The help command provides a short listing of all the maint commands. 
Run maint and enter «help» after the «?» prompt, as shown in Figure 
C-4.1. 

?help 


BASKET file name 

reorder basket 

HELP [command] 

print long command description 

EXIT (or EOF!) 

terminate execution of program 

DESK file name 

reorder desk 

FIX basket or desk 

recalc offset in desk or basket file 

BLIND 

delete bad blind box and reply records 

TEAR 

delete bad tear sheet records 

CLASS name or number 

reorder classifieds 

LOWERBOUND 

set blind box lower boundary 

UPPERBOUND 

set blind box upper boundary 

DUMP 

delete out of date dump item records 

STATS 

delete excess class stats records 

TRACKING 

maintain ad tracking file records 

EXTRACTS [fileset] 

build header extract records 


Figure C-4.1. Short help Directory for maint. 


Long Command Descriptions 

Detailed individual help commands provide explanations of each of the 
commands in the short help directory. The following paragraphs list these 
descriptions and the commands that display them. 

?h ba (BASKET HELP) 

The basket command, followed by a basket name, reads stories in a 
basket and updates headers. 

?h de (DESK HELP) 

The desk command, followed by a desk name, reads stories in a 
desk and updates headers. 

?h exit (exit help) 

The exit command exits maint. 

?h f (FIX HELP) 

The fix command, followed by the word «desk» or «basket», recalcu¬ 
lates the byte count and byte offset in either the desk or basket 
records definition file. 
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?h bl (BLIND HELP) 

The blind command reads through the blind box file and reads the ad 
associated with each blind box record. If the ad is not supposed to 
have a blind box, or the blind box number is different from the one 
listed in the ad number form, the blind box record is deleted. Blind box 
reply records are also deleted if there is no corresponding valid blind 
box. 



?h te (tear help) 

The tear command reads the tear sheet file and the ad associated 
with each tear sheet record. If the ad is not supposed to have a tear 
sheet, the tear sheet record is deleted. 

?h cl (class help) 

The class command, followed by a class name or number, reads the 
ads in that class and updates the headers. 

?h lo (LOWERBOUND HELP) 

The lowerbound command sets the lower limit on the range of blind 
box numbers. The lowest blind box number should be at least one (1). 

?h up (UPPERBOUND HELP) 

The upperbound command sets the upper limit on the range of blind 
box numbers. 


?h du (DUMP HELP) 

The dump command reads through the dump item record file and 
deletes out-of-date records. Dump item records for ads which have 
been purged are deleted. 



?h S (STATS HELP) 

The stats command deletes excess records in the class dump statis¬ 
tics files. The user enters the number of records to maintain in each of 
the files, by time period. (Statistics records are maintained on a daily, 
weekly, monthly, and yearly basis for each of the three stats groups: 
Class, Solicitor, and Account.) 

The stats command may also be run from a specified infile for 
convenience. 


?h tr (TRACKING HELP) 

The tracking command reads through the ad tracking file and de¬ 
letes records with nonexistent ad numbers. It also checks the com¬ 
pletion date in the tracking record against the ad header completion 
date. If they do not match, an error message giving the ad number will 
be logged to the outfile. To rectify these errors, call up the ad and its 

tracking record and update the completion date to match that in the 
header. 


?h ext (EXTRACT HELP) 

The extract command constructs and writes records to header ex¬ 
tract files. Enter the file name(s) to rebuild or all to build all header 
extract files which are defined in the configuration file. The records 
will be constructed according to the header extract definition indicated 
in the configuration file record parameter string. 

For example: extract Ssystem.class.extractO; $sys- 

tem.class.extractl, or extract all. 
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MAINT Error Messages 

The following messages may be given while you are using maint. Most 

messages occur immediately following the command entry which generat¬ 
ed the error. 

“Abbreviation not unique”—The command abbreviation is not understood. 
Add a sufficient number of letters to make the command recognizable 
to the system. 

“case statement index out of range”—There is a problem with the maint 
process. Contact your Sll System Engineer. 

“Command parameter missing”—A required string modifier is miss ing. 
Request detailed help for the command. 

“Couldn’t change to network form”—System was unable to access network 
mode. 

“Fatal i/o error in [file name]”—There has been an irrecoverable error. 

“Header update failed”—Failed to accept header resequencing command. 
Try again. The header may have been busy. 

“Invalid command”—The command is not recognized. Enter Help for a list 
of acceptable commands. 

“Key position or position failed for [file name]”—Probable hardware failure. 

“Missing system identifier”—The correct system not correctly specified. 
Ensure you are in the same system you are attempting to run maint 
against, or that the correct system is specified in the configuration file. 

“More than 10,000 active ads, class not sorted”—Input has exceeded a 
programmed limit. If this is a problem, contact your Sll System Engi¬ 
neer. 

“No config file entry found: blind box” —There is no Configuration file 
entry for the Blind Box file or it is improperly defined. See your System 
Manager. 

“No config file entry found: tear sheet”— There is no Configuration file 
entry for the Tear Sheet file or it is improperly defined. 

“No configuration file”—The Configuration file cannot be found. 

“No param expected, was ignored”—Improper or superfluous parameter 
entered. Enter «help» for correct placement of parameters. 

“No startup message found”—The system startup message was not re¬ 
ceived. Start maint again. 

“open failed for [file name]”—Either the file does not exist, or you do not 
have the authority to access it. 

“Sign on failed, maint in use”—Another user is running maint on the same 
basket. Two users may not run maint on the same basket simulta¬ 
neously. Discuss the difficulty with the other user; you may be work¬ 
ing at cross purposes. 

“Story [name and reason] was skipped”—The story was skipped when 
resequencing was attempted. Try again after a short wait. 


i 
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SECTION C-5 

REAUDIT 


REAUDIT reformats audit copies of take headers with a new header 
structure in the text file of a specified system. 

Running REAUDIT 

REAUDIT can be executed from Sll Command Interpreter. At the semi- 
colon pro mpt enter «reaudit» followed by the desired parameters and 
IREturni . For example: 

reaudit [/in (config)/] (old name), [(new name)], [(system)] 


(config)—the configuration file for the system. If the program is run from 
Sll Command Interpreter, this need not be specified. If a file name is 
specified, it overrides whatever is supplied by command interpreter. 

(old name) the structure name under which the old headers are format¬ 
ted. 


(new name) the structure name under which the new headers are to be 
formatted. If a new structure name is not specified, the structure 
name for the header file being reformatted is assumed. 


(system)—the system whose audit copies in the text file are to be refor¬ 
matted. If a system is not specified, the text file in the system under 
which Sll Command Interpreter is running will be reformatted. 

For example, if you wish to reformat a system which has just been 
updated so that the audit copies in the text file will correspond to the new 
format of the header file, you might use one of the parameter strinas 
below. 


To reformat the system under which an Sll terminal is running: 

reaudit old'header 


To reformat the editorial system from a Tandem Command Interpreter: 

reaudit /in Ssystem.systada.config/ old'header,,e 


To reformat all systems: 

reaudit oldSieader, , e 
reaudit oldSieader, , c 


To reformat the system before conversion: 

reaudit header, newsreader 


WARNING 

reaudit does not interlock stories as it reformats. 
The System/55 software ($zeus, $etw and so on) 
must be running for reaudit to be successful. 
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REAUDIT Error Messages 

The messages below may be given while you are using reaudit. Most 

messages occur immediately following the command entry which generat¬ 
ed the error. 

“nn Audit copies reformatted”—This message indicates the number of 
copies reformatted during this run of reaudit. 

“Can’t find”— reaudit could not locate a record in the configuration file. 

“Can’t handle numeric arrays”—The reformat cannot be performed. 

“Can’t open [filename]”—Either the file does not exist or you do not have 
the authority to access it. 

“i/o failed to [filename]”—There has been a hardware failure, the disk drive 
is not working properly, the file is full, etc. 

“keyposition failed to”—Contact your Sll System Engineer. 

“No fields to reformat”—You may have made an error in entering the 
reaudit run parameters. Recheck your entries. 

“No system specified”—You failed to specify a system in the run parame¬ 
ters. 

“Reformatting”—This message is displayed while reaudit is processing 
stories. It is for your information only. It does not indicate an error. 

“Reformat aborted!”—Reformatting could not be completed for some rea- 
" son. Contact your Sll System Engineer. 

“nn Stories read”—The number of stories read during this run of reaudit. 
This message is for your information only. It does not indicate an 

error. 

“nn Stories w/ audit copies”—The number of stories with audit copies in 
this run of reaudit. This message is for your information only. It does 
not indicate an error. 

“Structure too large”—The specified structure cannot be reformatted. 

“Too many fields”—The specified structure cannot be reformatted. 


SECTION C-6 

GCOPY Process 

GCOPY is the fgen/lgen form and list copying program. 

Executing the Program 

GCOPY can be started from SI I Command Interpreter. At the semicolon 
prompt enter «gcopy» followed by |return| . 

The Help Command 

GCOPY has a Help command. To use it, start the process and enter 
«help». All the available commands and a brief description of each will be 
listed. 

To display a more detailed description of a specific command, enter 
«help» followed by the name of the command. 


Interactively edit last command 
Print long command descriptions 
Specify the System IDs and 
CONFIG file names for the source 
and destination of subsequent 
FORM and LIST commands 
Copy a form definition 
Copy a list definition 
Print revision information 
Terminate execution of program 

figure C-6.1. gcopy Help Command. 


;gcopy 
) help 
Commands 
FC 

HELP command 
COPY from system 
from config 
to system 
to config 
FORM form name 
LIST list name 
VERSION 
EXIT (or EOF!) 


Available Commands 


COPY 

The copy command specifies the system ids and configuration file 
names to be used to find the names of the four files used to store Form 
and List definitions. The command is entered in the following format: 

copy (source system id), (source config file name), 

(destination system id), (destination config file name) 

The first two parameters specify the source of subsequent copies and 
the last two specify the destination. If the destination configuration file 
name is omitted it is assumed to have the same name as the source 
configuration file. Forms and Lists can be copied across the net by specify¬ 
ing configuration file names in network format. 

FORM 

The form command copies the specified form name from the two form 
files found in the source configuration file and system to the two form files 
found in the destination configuration file and system. 
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The command is entered in the following format: 

form (source name), (destination name) 

Any previous version of the form is overlaid by the new one. A new form 
name may be assigned for the form in the target system by following the 
form name with a comma and any suitable name not already in use in that 
system. This avoids overlaying the old form as described above. 


LIST 

The list command copies the specified list name from the two list files 
found in the source configuration file and system to the two list files found 
in the destination configuration file and system. 

list (source name), (destination name) 

Any previous version of the list is overlaid by the new one. A new list 
name may be assigned for the list in the target system by following the list 
name with a comma and any suitable name not already in use in that 
system. This avoids overlaying the old list as described above. 

VERSION 

The version command prints the build date, system revision, and pro¬ 
cess revision for gcopy. 


EXIT 

The exit command causes gcopy to exit. 


GCOPY Example 


In the example below, aform and alist will be copied from the Sll 
editorial system to the demo editorial system. They will be renamed 
bform and bust respectively. 


;gcopy 

)copy e, sii.$system.sysdata.config,e, demo.$system.sysdata.config, 
)form aform, bfdrm 
)list alist, blist 

Figure C-6.2. Sample gcopy to Copy aform and alist. 


CAUTION 

After forms and lists have been copied in this fash¬ 
ion, the copies at the destination should be rebuilt 
using the fgen/lgen Rebuild Command.(See 
Form Generation and List Generation S55-001). 


GCOPY Error Messages 

The following messages may be logged on the terminal while you are 
using gcopy. Most message occur immediately following the command 
entry which generated the error. 

“Command is not unique”—You have entered a command as a single 
character. More characters are required to make the command 
unique. 
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“copy statement required"—You must enter the copy command before 
specifying a form and/or list name. 


Fatal i/o error in [filename]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 


“Form name must be 1-12 characters”—The form name you have sup¬ 
plied exceeds 12 characters. 

“Form not found in form message file”—The form you have specified 
does not exist. 

“Form not found in form save file”—The form you have specified does 
not exist. 


“Incorrect config file:”—The file specified in the copy command is not a 
configuration file. 

“Incorrect form message file:”—The file cannot be read due to a hard¬ 
ware or software problem. Try again. If you get this message a 
second time, contact your Sll System Engineer. 


“Incorrect form save file:”—The file cannot be read due to a hardware or 
software problem. Try again. If you get this message a second time, 
contact your Sll System Engineer. 

“Incorrect list message file:”—The file cannot be read due to a hardware 
or software problem. Try again. If you get this message a second 
time, contact your Sll System Engineer. 



Incorrect list save file:”—The file cannot be read due to a hardware or 
software problem. Try again. If you get this message a second time, 
contact your Sll System Engineer. 


“Invalid copy parameters”—Recheck your entries for the copy command. 


“Invalid file name for network”—The specified file cannot be accessed 
across the network. 


“List name must be 1-12 characters”—The list name you have specified 
exceeds 12 characters. 


“List not found in list message file”—The list you have specified does not 
exist. 


“List not found in list save file”—The list you have specified does not 
exist. 


“New form name must be 1-12 characters”—The new form name you 
have specified exceeds 12 characters. 

“New list name must be 1-12 characters”—The new list name you have 
specified exceeds 12 characters. 

“New name cannot be blank”—You have entered a comma following the 
form name in the parameter string. A new form name was expected 
but none was supplied. 


“OPEN failed for [filename]”— Either the file does not exist or you do not 
have the authority to access it. 

“Unable to find ’from’ fmsg file in Config”—The file cannot be found on the 
source system. 

“Unable to find ’from’ form file in Config”—The file cannot be found on the 
source system. 
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“Unable to find ’from’ list file in Config”—The file cannot be found on the 
source system. 

“Unable to find ’from’ lmsg file in Config”—The file cannot be found on the 
source system. 


“Unable to find ’to’ fmsg file in Config”—The file cannot be found on the 
destination system destination system. 

“Unable to find ’to’ form file in Config”—The file cannot be found on the 
destination system. 


“Unable to find ’to’ list file in Config”—The file cannot be found on the 
destination system. 

“Unable to find ’to’ lmsg file in Config”—The file cannot be found on the 
destination system. 


“Unrecognized command”—The characters of the first word you have 
typed on the command do not match those of a gcopy command. 
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SECTION C-7 

FIXER 


FIXER allows you to recover the contents of damaged enscribe data 
files, fixer is not a file maintenance program, that is, it need not be run on 
a regular basis. It should be run if error 59 (file is bad) occurs or when the 
system is halted in an unorderly fashion. 

FIXER can be run while the system is up; however, it locks users out of 
files while it is working. If you must run fixer on a live system, notify users 
before executing the program. 

Executing the Process 

FIXER can be executed from Sll Command Interpreter. At the semico¬ 
lon prompt enter «fixer» followed by the name of the file you wish to fix. 


; fixer {f ile name) [Q 

Figure C-7.1. fixer Run Command Format. 


When fixer is executed, the specified file is fixed and examined. If it is a 
system configuration file, the program reads through it and fixes all of the 
files it references. This may take some time to complete. 


FIXER prompts each time it locates an error. Respond to the prompt 
with «y» (yes). 


If the optional exclamation point is included, the program will read and 
examine every block of a record number or entry sequenced file. Normally 
this is not necessary. 


In the example below, fixer is being executed on the editorial header 

(EDITOR.HEADER). 


;f ixer editor.he ader 

Figure C-7.2. Run Command to Execute fixer on Editorial Header File. 
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Q is an interactive process used to define and modify Q-fields. 

Q allows you to obtain information from files in a general manner. You 
describe fields which indicate the format of the information and assign 
symbolic names to the fields. The information contained in the fields can 
be displayed or modified at any time using a variety of techniques. 

Since this program deals with valuable data files, exercise care when 
running it. Only standard Tandem file security checks are made. No Sll 
checks are performed. (For example, no distinction is made between two 
different Sll users on the same Tandem account.) 

Executing the Process 

Q may be executed from Sll Command Interpreter. At the semicolon 
prompt, enter «q» followed bv IreturnI . 


Figure C-8.1. Executing q from Sll Command Interpreter. 



HELP 


Q has a Help command. To use it, enter «help» at the process prompt 
(Figure C-8.2). 



; g. help 
FC 

HELP [command] 
VERSION 
EXIT (or EOF!) 
VOLUME [name] 

FILE name [! ] 
STRUCT [name] 

ADD name [,def] 
MODIFY name 
REMOVE name 
LIST modifier 
DUP new'name 
ZERO name 
NAME new'name 
DEFAULT name 
UPDATE file 
[,name][!] 

PRINT name 
CHANGE name [=new] 
DUMP [modifier] 
LOAD 

PURGE [modifier] 
FORMAT file, name 
CLEAN file 


Interactively edit last command 
Print long command descriptions 
Display version information 
Terminate execution of program 
Set default volume and subvolume 
Open the named file [remove X-ref] 
Set the current structure 
Add a new field definition 
Modify a field definition 
Delete a field definition 
List field information 
Create duplicate structure 
Remove a structure en mass 
Rename a structure en mass 
Change the default offset for ADD 


Update some other Q-field file 
Print the value of the field 
Change the value of a field 
Display the contents of record/file 
Load a new record into file 
Delete a record from file 
Reformat data file 
Clean (story header) file 


Figure C-8.2. List of Commands Displayed by q Help Command. 
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To display a more detailed description of a specific command, enter 
«help» followed by the name of the command. 



Available Commands 


VERSION 

The version command displays the revision information for the pro¬ 
gram. 

VOLUME 

Enter: 

volume (name) 

This command changes the default volume/subvolume specification. 
The current volume and subvolume is displayed if no name is supplied. 


FILE 


Enter: 

file [!] 

This command opens the named file for access. The file is looked up in 
a cross reference file which determines the structure q uses when access¬ 
ing the file. If the file is not the cross reference file or the exclamation point 
is supplied, you are prompted for the default structure and your response 
is saved for future use. If you do not have write access to the data file, the 
program attempts to open the file read-only. 

STRUCT 

Enter: 

struct (name) 

This command changes the current structure to the name given. If no 
name is supplied, the name of the current structure is displayed. 



ADD 

Enter: 

add (name) [, def] 


This command allows you to add new fields to the data base. If the 
optional field definition information is not given, you are prompted for the 
information required. The format of the field information is fairly complicat¬ 
ed and is described later in this section under “Entering Q-field information 
in compressed format. 

MODIFY Command 

Enter: 

modify (name) 




are prompted 
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REMOVE 

Enter: 

remove (field name) 

This command removes the named field from the data base. 

LIST 

Enter: 

list (modifier) 


This command lists a subset of the Q-field data base as specified by the 
modifier. The list command displays field offsets in octal as well as 
decimal. This makes it easier to compare a q structure listing with its 
corresponding tal structure listing. 

The following commands may be used: 

LIST ALL- 

LIST file (name)—lists the fields implied by the named file. 

list struct (name)—lists all fields in the named structure. If no structure 
name is supplied, the fields in the default structure are listed. 

list field (name)—lists all fields with the given name regardless of the 
structure they are in. 

DUP 

Enter: 

dup (new'name) 


This command creates a duplicate of the current structure with the new 
name specified, dup is usually the first step used in conjunction with the 
format command to reformat a file. 

ZERO 

Enter: 

zero (name) 


This command deletes the entire structure from the field definition on 
file. It is normally used during the reformatting process. You are reprompt¬ 
ed to make sure that this is what you want to do. If you are not running q 
interactively, you are not reprompted. Make certain you know what you 
are doing. 

DEFAULT 

Enter: 

default (name) 


The default command is used to change the default offset used by the 
add command when you do not specify an offset. The default offset is set 
to the offset of the field specified in the command. 
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UPDATE 


Enter: 

update (q-file) [, name] 


[! 1 



The update command is used to update some other Q-field file. It 
copies the currently specified structure to the file specified. If the optional 
structure name is supplied, the fields written to the new Q-field file are 
written with that new structure name. If the optional exclamation point is 
specified, existing fields in the destination structure are deleted before the 
new fields are copied. 


PRINT 


Enter: 

print (name) 


This command prints out the value of the named field. The value is 
normally typed out in its default i/o mode (see “General Purpose 1 / 0 " later 
in this section). This may be overridden by placing a slash and the desired 
i/o mode after the field name. 

CHANGE 

Enter: 

change (name) [=new] 


This command allows you to change the value of a field. This is not 
always possible, for instance, the file may be read-only. If no new value is 
supplied, the current value is printed first and you are prompted for a new 
value. 


DUMP 

Enter: 

dump (modifier) 


The dump command prints out the contents of a subset of the current 
file as indicated by the modifier chosen: approximate, generic, or exact. 
The modifier indicates the mode for the keyposition. You are prompted 
for a path and key specification. If no modifier is supplied, the entire file is 
dumped. 

LOAD 

Enter: 

load 


This command prompts you for a new record to add to the current file. If 
the file is a relative file, you are prompted for a key. 

PURGE 


Enter: 

purge (modifier) 

cuTOnt P rte G Th«' a "° WS y ° U 10 dele,e a subset °' records 'he 
current file. The modifiers approximate, generic, and exact are avail- 


.........v.-m-* 
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FORMAT 


Enter: 

format (file name) 


The FORMAT command reads the current file (using the current default 
structure) and writes it reformatted to the named file using the named 
structure. The destination file can be the new data base file, or if insuffi¬ 
cient disk space or other reasons require it, the destination file can be a 
tape, which can later be copied to the new disk file using fup. Only 
structured files may be reformatted. 

When using the format command, if the q structure length exceeds the 
destination record length, a warning message is displayed (“Structure 
exceeds record length”) before reformatting takes place. This allows you to 
reformat q structures which contain pseudo or transient fields which are 
not actually part of the record. 

If duplicate records exist in the source and destination files, the format 
command will overwrite the record in the destination file with the reformat¬ 
ted record. This allows you to reformat files when the source and destina¬ 
tion files are the same. 

CLEAN 

Enter: 

clean (file name) 


The clean command is used in preparation for reformatting a story 
header file. It removes story header records that are only one byte long. 


General Purpose I/O 

Values in q can be displayed in several different i/o modes: 

1. Binary 

2. Octal 

3. Decimal 

4. Hexadecimal 

5. ASCII 


The mode to use is indicated by the first character of the number to 
input: 


1 . 

2 . 

3. 

4. 

5. 



A single quote for binary, 

a percent sign for octal, 

nothing or a plus or minus sign for decimal, 

a slash for hexadecimal,and 

a double quote for ascii. 

The i/o mode to use on output is the default mode stored with the field 
definition. It can be changed permanently with the modify command, or 
temporarily with a switch on the print and change commands. 

String variables are automatically input and displayed in ascii, no 
quotes are needed to input a value to a string variable. On output, string 
variables are typed out enclosed in braces not quotes. This is to 
reinforce the fact that strings are entered without quotes. 
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Structured Files 


In general, whenever you reference a structured file with q, the program 
needs to know on which record you are going to perform the operation. 


When you reference a structured file, you are prompted for an access 
path (if the file has alternate keys) and a key. Zero is the primary path. The 
key may be entered in any format (see “General Purpose I/O” above) that 
you wish. A single limitation is placed on key sequenced files: the length of 
the primary key must be less than or equal to 256 bytes (the same 
limitation is placed on alternate keys by enscribe). If the primary key is 
longer than 256 bytes, then you must access the file through some alter¬ 
nate key. 


Q-Field Information 


struct name —a maximum of 16 alphanumeric or caret (hat) characters. 

field name —a maximum of 16 alphanumeric or caret characters. 

offset— the offset from the beginning of the file for unstructured files and 
the offset in the record for structured files. 


array length —the array length of the field. This is the length of the text 
string, or the number of array elements in the byte, int, long, or 
quad arrays. 

edit code —the standard five digit octal edit code. 

type —the type of field to reference. 

i/o code —the preferred type of out. 

start bit— the beginning bit in the bit field to be referenced. 

end bit —the ending bit in the bit field to be referenced. 


report heading— the text string printed out in reports. Used by the list 
generation and report generation programs (lgen and rgen). 

form heading —the text string printed out in forms. Used by the form 
generation program (fgen). 

output width— the width to use in outputting the number in a form or 
report. 


Entering Field Information in Compressed Format 

If the optional compact format for the add command is used the various 
pieces can be entered, separated by commas (null fields default the same 
way as the prompted form of the add command). The field information 
should be entered in the following order: 

field name— the name of the field 


error name— the error name (used by vget and vtab) 

type— bit, byte and so on 

length— the number of items in the field 

read— the read level for the field 

write— the write level for the field 

report the report name (default in lgen) 


C-8.6 





System Managers Manual 


Q 


form— the form name (default in fgen) 
width— the output width of the field 
edit— the edit code 

i/o code— the i/o code (binary, octal, decimal, hexadecimal, or ascii. ) 
offset— the record offset of the field 
START BIT—the first bit of a bit field 
end bit— the last bit of a bit field 


Specifying an Index Value for Field Offset 

When defining the offset of a field which has been equated to another 
field, you may specify an index value to be added to the computed offset 
for the field. For example: 

some"field,,string,10,0,0,Name, Name, 10 

next'field, , string, 5, 0, 0, Name, Name, 5, , , some'field [5] 


In this example, the offset for next'field will be equated to the offset of 
some'field plus five bytes. 

The [index] value is always taken to be the number of bytes to add to the 
offset, regardless of the data type of either field. [Index] values must be 
positive. 


Q-Field Types 

When adding or modifying Q-fields (with the add or modify commands), 
you must choose a field type from the list below. 

bit— an array of single bits. The first bit is 0. 


byte —an array of single bytes. A bit field may be specified. For example, 
you could define two fields which access the left or right halves of the 
byte. 


int —an array of single integers. All multi-byte types may be placed any¬ 
where in the file, they do not need to be word aligned. Fields may be 
described for the int data type similarly to fields for the byte data 
type (except that the available bits are 0 to 15 instead of 0 to 7). 

long —an array of double word integers (that is, 32 bits long). 

quad —an array of quadruple word integers (that is, 64 bits long). 

string —an array of bytes which are treated as a single entity. Strings 
always use ascii i/o mode, so no quotes are needed on input. 

ucase —similar to a string except that the input string is converted to 
uppercase before it is stored. 


file— similar to an uppercase string except that what is stored is the result 
obtained from passing the input through the fnameexpand proce¬ 
dure. This output may be either 16 bytes long (a volume/subvolume 
field) or 24 bytes long (a complete Tandem file name). Note that what 
is stored is the internal form of the file name, suitable for calls to open. 
Before it can be displayed, however, the file must be converted to 
external form by using fnamecollapse. 
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Q Error Messages 

The following messages may be given while you are using q. Most 

messages occur immediately following the command entry which generat¬ 
ed the error. 

“Already exists”—The field or record already exists. 

“Array index out of range”—Recheck your specifications for the field index 
value. 

“Can only reformat structured files”—The file you have specified is not a 
structured file. 

“Can’t create formatting process”—Try again. If you get this message a 
second time, contact your Sll System Engineer. 

“Can’t reformat numeric arrays"—You have attempted to reformat an int 
Q-field. 

“case statement index out of range”—Contact your Sll System Engineer. 

“Changing the primary key is not allowed”—You have attempted to 
change the primary key. 

“Conflicting bit positions”—Recheck the bit positions you have specified. 

“Duplicate in unique alternate key field”—An alternate key must be 
unique. 

“Fatal i/o error in [filename]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 

“File is read-only”—You have read-only access to the file you have speci¬ 
fied. You cannot write data to it. 

“Illegal data type”—You have specified an illegal data type. Recheck your 
entries. 

“Illegal i/o type”—You have specified an illegal i/o type. Recheck your 
entries. 

“Illegal syntax”—Q cannot decode your entry on the command line. 

“Invalid access level”—You have specified an invalid access level for a 
field. Valid access levels are 0-10. 

“Invalid bit number”—You have specified an invalid bit number for a field. 
Valid bit numbers are 0-15 or 0-7. 

“Invalid edit code”—You have specified an invalid edit code. Recheck your 
entries. 

“Invalid file name”—You have specified an invalid file name. Recheck your 
entries. 

“Invalid offset”—You have specified an invalid offset for a field. Recheck 
your entries. 

“Invalid output width”—You have specified an invalid output width for a 
field. Recheck your entries. 

“Item overflows record”—The structure is bigger than the actual record. 

“Length of file fields must be 16 or 24”— file may only be 16 or 24 bytes 
long. 

Missing array length”—You have omitted the array length for the field. 
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Missing closing quote”—You have omitted a closing quote.i 

Missing ending bit”—You have not specified an ending bit for the field. 

Missing parameter”—You have omitted a command parameter. 

Missing ’]’”—You have omitted a closing bracket. Recheck your entries. 

No number found”—A number was expected but was not found. 

No startup message found”— q did not receive the startup message it 
expected from Sll Command Interpreter. Try executing q again. If you 
get this message a second time, contact your Sll System Engineer. 

No such field name”—The field you have specified does not exist. 

No such path”—The path you have specified does not exist. 

No such structure”—The structure you have specified does not exist. 

No file has been specified yet”—This message is for your information 
only. It does not indicate an error. 

No default structure for”—This message is for your information only. It 
does not indicate an error. 


“Not a Q-field file”—The file you have specified is not a Q-field file. 

“Not unique”—You have entered a command as a single character. More 
characters are needed to make the command unique. 

“Old and new fields are incompatible”—The fields you have specified 
cannot be reformatted. 

“open failed for [filename]”—Either the file does not exist or you do not 
have the authority to access it. 

“Parameter string is too long to process”—Edit the parameter string until it 
is short enough to be processed. 

“Position generic allowed only on key-seq files”—This message is for your 
information only. It does not indicate an error. 

“Position not exact”—Position must be exact. 


“purge command only acts on structured files”—This message is for your 
information only. It does not indicate an error. 


“Reformatting ’’—This message is displayed while reformatting takes 
place. It is for your information only. It does not indicate an error. 


“Structure length exceeds record length”—This warning is given when 
pseudo fields are found. 

“That key is too long to process!”—The key must be less than or equal to 
256 bytes. 


“Too many fields to reformat”—There are too many fields. Reformatting 
cannot proceed. 


“Unable to lock record”—The record is in use or it does not exist. 

“Unexpected character”—An invalid character was found on the command 
line. Recheck your input. 


“Unknown modifier”— q does not recognize the modifier you have entered. 
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“Unrecognized command”—The characters of the first word you have 
typed on the command line do not match those of a q command. 

“Unrecoverable error in formatting process”—Contact your Sll System 
Engineer. 

“Warning: No fields in default structure”—This message is for your infor¬ 
mation only. It does not indicate an error. 
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SECTION C-9 

TDUMP 


TDUMP converts binary character input from a specified take to hexa¬ 
decimal and graphic characters and outputs it to a specified file, tdump 
cannot be used to process stories flagged private. 

TDUMP gives both a hexadecimal and character listing of any story 
stored in the system. The hexadecimal is given on the top line with up to 3 
characters of graphic on the line below (Figure C-9.1). Only the first two 
records will be dumped unless you specify otherwise. 


Running TDUMP 

TDUMP can be executed from Sll Command Interpreter. At the semico¬ 
lon prompt enter «tdump» followed by the desired parameters. For exam¬ 
ple: 

; tdump/.in ^system, sxsdata. conf igj_ out $s.^tdumpt S 

$system.sysdata.config— the configuration file name. 

$s.#tdump —the output file name. If an output file is not specified, the 
results are displayed on the terminal from which the program is 
executed. 


e —the system identifier. In this case editorial. 

tdump —the name of the story to dump. If the first character is «#», the 
characters are assumed to be the story number. 


5—the number of records to dump. If the number of records is not speci¬ 
fied, tdump defaults to «2». 


Delimiting Character 

The character following the system identifier is the delimiting character. 
If a comma is used in the story name, the delimiting character can be 
changed to any other special character. 


0D0: 

00 00 

00 

00 

00 00 

00 00 

00 00 

20 

40 

00 3C 

54 68 


NULNUL 

NULNUL 

NULNUL 

NULNUL 

NULNUL 


@ 

NUL< 

T h 

0D8: 

69 73 

20 

74 

65 78 

74 20 

69 73 

20 

6F 

6E 6C 

79 20 


i s 


t 

e x 

t 

i S 


0 

n 1 

y 

0E0: 

66 6F 

72 

20 

75 73 

65 20 

69 6E 

20 

74 

65 73 

74 69 


f o 

r 


u s 

e 

i n 


t 

e s 

t i 

0E8: 

6E 67 

20 

74 

68 65 

20 6F 

70 65 

72 

61 

74 69 

6F 6E 


n g 


t 

h e 

o 

P e 

r 

a 

t i 

o n 


Figure C-9.1. Sample tdump listing. 
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TDUMP Error Messages 

The following messages may be given while you are using tdump. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 


“Cannot dump personal stories”—Stories flagged privated cannot be ac¬ 
cessed with TDUMP. 


case statement index out of range”—Contact your SI I System Engineer. 

“Configuration entry not found”—The system configuration file is incorrect 
or incomplete. Contact your Sll System Engineer. 

“Fatal i/o error in [filename]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 

“Invalid record count”—You may have entered the comma following the 
story name without specifying the number of records. 

“Invalid story number”—The name of the story to dump started with “#” 
but was followed by non-numeric characters. A story number was 
expected. 


“Missing delimiter”—You have omitted the delimiting character following 
the system identifier. 

“Missing story name/number”—You have not specified a story to be 
dumped. 

“Missing system identifier”—You have not entered a system identifier. 

“No startup message found”— tdump did not receive the startup message 
it expected from the Sll Command Interpreter. Try executing tdump 
again. If you get this message a second time, contact your Sll System 
Engineer. 


“No such story”—The story you have specified to be dumped is not found. 

“Number of records dumped”—This message is given after tdump has 
completed. It does not indicate an error. 


“open failed for”—Either the file does not exist or you do not have the 
authority to access it. 


C-9.2 


System Manager^ Manual 


CORED 


SECTION C-10 

CORED 


CORED is an interactive process used to display and modify the con¬ 
tents of a file in hexadecimal or octal format. When not run interactively, it 
dumps an entire file in hexadecimal format. 

Running CORED Interactively 

Start Sll Command Interpreter ( Icmdi [3). At the semicolon prompt, 
enter «cored» followed (optionally) by the name of the file you wish to 
dump. If a file is not specified, it defaults to $system.ga.core. 

The command syntax required to dump a file to an out file is illustrated in 
Figure C-10.1 


; cor ed/out$(out"f i 1 e) /(f i lename) 

FIGURE C-10.1. cored Command to Dump Entire File. 


The Help Command 

CORED has a Help command. To use it, start the process and enter 
«help». All the available commands and a brief description of each will be 
listed. To display a more detailed description of a specific command, enter 
«help» followed by the name of the command. 


Evaluating Expressions 

This command allows you to evaluate an expression of the form: 

N1 op N2 op. . .op N where op is 4-, *, or /. 

Enter: 

= (expression) 


Display Portion of the File 

d allows you to display portions of the file, da will display it in ascii as 
well, a displays the file in ascii only. 

Enter: 

d(expression) [, [count] [, $(device)] ] 


Modify Location in File 

m allows you to modify a location in the file. If the comma is included, the 
location will be modified without prompting. 

Enter: 


m(expression) [.(value)] 
page 


Set Base 


b allows the setting of a base for subsequent additions to address 
expressions. 
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Enter: 

b(base value) 


Specify Different File 

f allows you to specify a different file. 

Enter: 

f (filename) 

Switch to Decimal I/O 

When «#» is entered by itself it allows you to switch to decimal i/o. 
When entered followed by a series of digits, it indicates that the number 
following is in decimal. 

Enter: 

# 

Switch to Octal I/O 

When «%» is entered by itself it allows you to switch to octal i/o. When 
entered followed by a series of digits, it indicates that the number following 
is in octal. 

Enter: 

% 

Switch to Hexadecimal 

When «/» is entered by itself, it allows you to switch to hexadecimal i/o. 
When entered followed by a series of digits, it indicates that the number 
following is in hexadecimal. 

Enter: 

/ 


CORED Error Messages 

The following messages may be given while you are using CORED. Most 

messages occur immediately following the command entry which generat¬ 
ed the error. 

“Can’t open [filename]”—Either the file does not exist or you do not have 
the authority to access it. 

“Current disk file is”—This message supplies the name of the current disk 
file. It is for your information only. It does not indicate an error. 

“Device is not a disk file”—You did not specify a disk. 

“File is empty”—The file you attempted to dump is empty. 

“How did you get here?”—Contact your SI I System Engineer. 

“i/o failed to”—There has been a hardware failure, the disk drive is not 
working properly, the file is full, etc. 
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“Invalid core file name”—The specified file is not a disk. 

“Unrecognized command”—The characters of the first word you have 
typed on the command line do not match those of a cored command. 
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PRINT 


O SECTION C-11 

PRINT 

PRINT is the spooler print process used to write a message to a device 
as soon as the device is available. 

Running PRINT 

PRINT can be executed from Sll Command Interpreter. At the semico¬ 
lon prompt, enter «print» followed by the name of the device and the 
message which is to be written to the device. 

The example in Figure C-11.1 illustrates the format for the print run 
command as it might be used to write to a line printer. 


;print/put$lp/This.isatest 

Figure C-11.1. Sample print Run Command. 


PRINT Error Messages 

When an error occurs, print logs the error message on the vdt from 
which the process was executed followed by the Tandem error number 
(represented by “nn” below). For an explanation of the error, at the semico¬ 
lon prompt enter the error number followed by (return]. 

“Cannot open log file, error: nn” 


“Cannot open $receive file, error: nn” 
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SECTION C-12 


PRINTH 


PRINTH writes a high priority message to a device (for example a line 
printer or system console typer). High priority messages cause low priority 
messages to be bumped. Thus, with this program, you can write to a 
terminal even if the Sll Command Interpreter is prompting. However, 
printh will not interrupt econtrol to write to a vdt. 


Running PRINTH 


PRINTH can be executed from Sll Command Interpreter. At the semico¬ 
lon prompt, enter «printh» followed by the name of the device and the 
message which is to be written to the device. 

The example in Figure C-12.1 illustrates the format for the printh run 
command as it might be used to write to a line printer. 


;p rin th /out $lp/ This is a test 


Figure C-12.1. Sample printh Run Command. 


PRINTH Error Messages 


The following messages may be given while you are using printh. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 

“case statement index out of range”—Contact your Sll System Engineer. 

“Fatal i/o error in [filename]”—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 

“No startup message found”— printh did not get the startup message it 
expected from the Sll Command Interpreter. Try executing printh 
again. If you get this message a second time, contact your Sll System 
Engineer. 

“open failed for”—Either the file does not exist or you do not have the 
authority to access it. 
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SECTION C-13 

STTY Process 


STTY allows you to modify the data communications parameters of a 
terminal. The parameters are modified in memory and are not retained 
after a processor reload. 

STTY can also be used to change communications control blocks 
(ccbs) of non-terminal asynchronous line devices of device type 7, sub- 
type 40 (for example wire services connected directly to the Tandem). 


Executing the Process 

STTY can be executed from Sll Command Interpreter. At the semi-colon 
prompt enter «stty» followed bv IreturnI . 


The Help Command 

STTY has a Help command. To use it, start the process and enter 
«help». All the available commands and a brief description of each will be 
listed. 


To display a more detailed description of a specific command, enter 
«help» followed by the name of the command. 


; stty 


)help 


Commands 


FC 

Interactively edit last command 

HELP command 

Print long command descriptions 

EXIT (or EOF!) 

Terminate execution of program 

TERM (name) 

Specify terminal fo modify 

SHOW 

Show terminal parameters 

STORE 

Store new parameters 

BAUD (rate) 

Set baud rate 

PARITY (type) 

Set parity (ODD/EVEN/NONE) 

CHAR (size) 

Set character size (5-8) 

TPAUSE ON/OFF 

Set TPAUSE status 

ECHO ON/OFF 

Set ECHO status 

PAGE 

Set page mode 

CONV 

Set conversational mode 

CHECK 

Enable parity checking 

NOCHECK 

Disable parity checking 

CURLOOP ON/OFF 

Set current loop status 


Figure C-13.1. stty Help command. 



TERM 


Allows you to specify the name of the terminal or ccb whose character¬ 
istics you wish to modify. For example, $term4. 


SHOW 


Lists the parameters for the terminal specified with the term command. 
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STORE 

Stores the new parameters, as set with baud, parity, and so on, for the 
specified terminal. 

BAUD 

Allows you to specify the baud rate for the terminal. 

PARITY 

Allows you to specify the parity type to be generated (even, odd, or 

NONE). 

CHAR 

Allows you to specify the number of bits per character. 

TPAUSE 

Enables (on) or disables (off) tpause checking. 

ECHO 

Enables (on) or disables (off) the echoing of input characters. 

PAGE 

Puts the terminal in page mode. 

CONV 

Puts the terminal in conversational mode. 

CHECK 

Enables parity checking. 

NO CHECK 

Disables parity checking. 

CURLOOP 

Specifies whether the device is current loop (on) or not (off). 


Running STTY 

Follow the steps below when running stty. Note that for the purposes of 
example, the device $term4 is used. 

1 . Take the device down using pup. 

:pupdown$term4 

Figure C-13.2. The pup down Command. 


2. Start the utility from Sll Command Interpreter. At the semicolon prompt 
enter «stty» followed bv l return! . 


; stty 

> . 



Figure C-13.3. Starting stty. 
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3. Use the term command to select the device to be modified. 


; stty 

)term $term4 


Figure C-13.4. The stty term command. 


4. Use the show command to display the current characteristics for the 
device. 


)term $term4 
)show 

BAUD4800 CHAR5 ECHO CONY NONE CHECK NOCURLOOP 


Figure C-13.5. The stty show Command. 

5. Use the modification commands to make the desired changes to the 
device characteristics. 


)term $term4 
)baud 9600 
)parity even 
)char 7 

C-13.6. Commands to Modify Characteristics of $term4. 


6 . 


Execute the show command once again to verify that you have it right. 


)show 

BAUD9600 CHAR7 ECHO CONY EVEN CHECK NOCURLOOP 


Figure C-13.7. Verifying Changes with the show Command. 


7. Use the store command to store the modifications for the terminal. 


)baud 9600 
)parity even 
)char 7 
)store 
)exit 

Figure C-13.8. Storing the Modifications to the Characteristics for $term4. 
8. Bring the device up using pup. 


;pup_ up $term4 

Figure C-13.9. pup Command to Bring up Device $term4. 
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STTY Error Messages 

The following messages may be given while you are using stty. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 


“Can’t find pdt for specified logical device”—Contact your Sll System 
Engineer. 


“Can’t find device in ldt!”— Contact your Sll System Engineer. 

“case statement index out of range!”—Contact your Sll System Engineer 

“cpu down, tcb/ccb inaccessible”—The cpu is down and the parameters 
for the specified device cannot be modified. 

“Device is not an asynchronous device”— stty can only be used to modify 
the parameters of asynchronous devices. 

“Device name cannot be in network form”—Only devices on the local 
system may be modified with stty. 


“Fatal i/o error for [filename]”—There has been a hardware failure, the 
disk drive is not working properly, the file is full, etc. 

Function not applicable to this type device”—The modifications you have 
specified cannot be performed on the device you have specified. 

open failed for [filename]”—Either the file does not exist or you do not 
have the authority to access it. 

“Illegal baud rate”—You have specified a baud rate which is not available. 


Illegal character size”—You have specified a character size which is not 
available. 

Illegal parity specification”—You have specified an unknown parity mne¬ 
monic. 


“Illegal value”—You have specified a value for a parameter which is not 
applicable for the device. 


Junk found on command line”—The program cannot decode your entry 
on the command line. 


“Missing parameter”—You have entered a value for a parameter without 
specifying the parameter. 

newprocess failed” Try again. If you get this message a second time 
contact your Sll System Engineer. 

No device has been specified yet”—You have attempted to issue a 
command without out first selecting a device with the term com¬ 
mand. 


Not unique You have used a non-unique abbreviation for a command. 
For example curloop may be abbreviated «cu» but not «c». 

“No startup message found!”— stty did not receive the startup message it 
expected from the Sll Command Interpreter. Try executing stty 

again. If you get this message a second time contact your Sll System 
Engineer. 


No value specified You have entered a command to change a parame¬ 
ter without specifying the new parameter. 

“Only parity command meaningful for this type device”—The modifi 

cations you have specified cannot be performed on the device you 
have specified. J 
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“on or off must be supplied”—You have entered a command which must 
be set on or off (tpause, echo, curloop) without specifying your 
choice. 

“Unknown alternate startup message function!”—Contact your Sll System 
Engineer. 

“Unknown command”— stty does not recognize the command you have 
entered. 
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MUX 


SECTION C-14 

MUX Process 


MUX allows you to monitor the activity of muxprocess lines and manip¬ 
ulate the parameters of vcus and tcus. 


Executing the Process 

MUX is executed from Sll Command Interpreter. At the semicolon 
prompt enter «mux» followed by (return]. 


The Help Command 

MUX has a Help command. To use it, start the process and enter 
«help». All the available commands and a brief description of each is 
displayed. 

To display a more detailed description of a specific command, enter 
«help» followed by the name of the command. 


; mux 


)help 


FC 

Interactively edit last command 

HELP command 

Print long command descriptions 

EXIT (or EOF! ) 

Terminate execution of program 

STATS 

Display line statistics 

LINE (name) 

Pick a line to alter 

SHOW 

Display line parameters 

DEBUG 

Debug a MUXPROCESS line 

USE (number lines) 

Specify number of logical lines 

DOWN (vdt) 

Down a single VDT 

UP (vdt) 

Up a single VDT 


Figure C-14.1. mux Help Command. 



Note that for mux running on TNS II systems, the use command is 
replaced by set (explained later in this section). 

STATS 

The stats command displays the line statistics for all muxprocess 
lines. 


; mux 







)stats 

Line 

Good 

Byte 

Bad 

NAK 

BCC 

Overrun 

Name 

Sessions 

% 

Sessions 

Count 

Errors 

Errors 

$A0 

43236 

75 

2 



l 

$A1 

21217 

67 

1 



1 

$A2 

0 


7 




$A3 

28036 

74 

1 




$C0 

0 







Figure C-14.2. Sample stats Listing. 
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Bad Session Messages 


Bad session messages (listed alphabetically below) are displayed on 
the $aopr log or on the system console, whichever has been specified as 
the outfile. 


bt —Buffer Timeout. 

Tandem system resource problem. The i/o could not be completed. 
The program will try to get the buffer again. You can’t get this mes¬ 
sage if you are running on a tns ii. 

bc —BadCommstat. 

A communication status buffer was expected from the vcu/tcu but 
was not received. 


df —Bad Data Function. 

A data buffer was received correctly, but it was not formatted as 
expected. 


en—enq in Session. 

An enq was received when text was expected. The device and mux- 
process are no longer synchronized. Usually this error is only printed 
once and then the two programs get back in sync. 

et— No ETX. 

etx received without a leading stx. 


ic —Illegal Control. 

A control character other than enq or nak was received. 
ip —Can’t ipl. 


An ipl request was received. Either there is no downld process 
running or the program did not receive the ipl buffer (applies only to 
vcus). 


nc—nak Count. 

Too many consecutive naks received. 
po —Power On. 

An i/o power on interrupt was received. 
to —Read Operation Timeout. 

This message is given when a read did not complete within the time 
allotted. Usually this means that the vcu/tcu/sync Coyote (hereafter 
referred to as “device) is not functioning. You won’t see this cause on 
a bad session error because it has its own no response error. 

tx —Unexpected Text. 

Text received when enq expected. Similar to en. 
wo—Write Operation Timed Out. 

A text write or control character write did not complete within the time 
alloted. Most of the time this occurs when the device has been 
powered off, or when the mode switches on the controller are set 
incorrectly. 


wt —Wrong Terminal. 

Data was received correctly but the data was for the wrong vdt. 

LINE 

The line command is used to select a line so that its current parameters 
can be displayed or so the parameters may be altered with the alter 
command. 
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; mux 

)line$a3 


Figure C-14.3. Selecting a Line with the line Command. 


SHOW Command on TNSI 

The show command displays the line parameters for the line selected 
with the line command (Figure C-14.4). 


)line$a3 

)show 

Supports only 16 logical lines. 

Read timeout = 2.00, session timeout = 60.00 seconds 
Minimum baud rate is 32.0 kb. 


Figure C-14.4. show Listing for Line $A3. 


SHOW Command on TNS II 


When executed on a TNS II system, the mux show command displays 
slightly different information. 


)line$a3 

)show 

Currently configured for a VCU 

Read timeout = 2.00, session timeout = 60.00 seconds. 
Minimum baud rate is 80.0 kb. 


Figure C-14.5. show Listing for Line $A3 on TNS II. 


DEBUG 

The debug command is used to debug a muxprocess line. This com¬ 
mand should be used only by Sll Personnel. Used incorrectly it could 
cause a processor halt. 

USE (TNS I Only) 

The use command allows you to specify the number of logical lines that 
muxprocess should allow. (This command is replaced by set on TNS II 
systems). 

SET (TNS II Only) 

The set command allows you to change the line type of the current line. 
If you did not take the line down, muxprocess will reject the command. 


DOWN 

The down command downs the specified vdt. The vdt name is normal¬ 
ly specified with the line name and the period removed (for example, #toi , 
or #R05). 
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UP 

The up command ups the specified vdt. The vdt name is specified 
normally with the line name and the period removed (for example, #toi , or 
#R05). 
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MUX Error Messages 

The following error messages may be given while your are using mux. 
Most messages occur immediately following the command entry which 
generated the error. 

“case statement index out of range!”—Contact your Sll System Engineer. 

“Fatal i/o error in [filename]"—There has been a hardware failure, the disk 
drive is not working properly, the file is full, etc. 


“Illegal subdevice name”—You have specified an illegal subdevice name. 
Recheck your entries. 

“Illegal value”—You have specified an illegal value on the command line. 
Recheck your entries. 


“Junk found on command line”— mux cannot decode your entry on the 
command line. 


“Line is not accessible”—The line you have specified cannot be accessed. 

“Missing parameter”—You have entered a command which requires a 
parameter without supplying a parameter. 

“muxprocess returned”—There has been an error with muxprocess. 


“No line specified”—You have entered a line modifying command without 
first specifying a line. 


No startup message found!”— mux did not receive the startup message it 
expected from Sll Command Interpreter. Try executing mux again. If 
you get this message a second time, contact your Sll System Engi¬ 
neer. 


“No such device”—You have specified a device which does not exist. 


“Not a valid device”—The device you have specified cannot be modified 
with mux. 


“open failed for [filename]”—Either the file does not exist or you do not 
have the authority to access it. 

“Not unique”—A command has been entered as a single character. More 
characters are required to make the command unique. 

“No value specified”—You have entered a command without specifying a 
value. 

“Security violation”—You do not have the authority to perform the opera¬ 
tion you requested. 

“Unknown command”—The characters of the first word typed on the 
command line do not match those of a mux command. 


M 



You are running on the line you want to debug!”—The debug cannot be 
performed. See the section on the debug command for additional 
cautions. 
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SECTION A-1 

Desk and Basket Definition 

Desks and baskets are the means by which you may organize the takes 
in your text file. All desks and baskets which are referenced by name in 
User Profiles must be defined prior to the process of user definition. 

Desk Definition 

Each desk is defined by completing a Desk Profile form as shown in Figure 
A-1.1. Each form is a separate record in the file «$system.editor.desk». 
Different sites may have different desk file names and desk files for additional 
systems. 

The Desk Profile form name (conventional name is «desk») is used in 
accessing the record with the various levels of [cmdI [f] (Edit, Copy, or 
create Record with Form). 

In the Desk Profile forms the fields are assigned literal names to clarify 
their meanings, and those are the names by which the fields are known in 
this discussion. To help identify a field’s literal name with its Q-field name 
(in structure «desk»), the name of the Q-field is given in brackets following 
the literal name: "Description [desc]». 


Desk Profile of 


Description 

Created by . 


. at 

Changed by . 



Access _ Assign _ 
Sorted (L, F, A or 

List Name 

R) _ by (field name) 


Figure A-1.1. Desk Profile 


Desk Profile Field Descriptions 

desk profile of [name] —The name of the desk (12 characters). Any 
ascii character available on your printer may be used, including spe¬ 
cial characters. This permits the name to be printed in hardcopy lists 
and reports. All names are converted to uppercase. 

description [desc] —A required description of the use of the desk. This 
description is useful information in an index of desks. 

created by . [created'by] —An information-only field displaying 

the name of the user who created the desk. 

on.[created'date] —An information-only field displaying the date on 

which the desk was created. 

at [created'time]— An information-only field displaying the time of 

creation. 

Note: The following three fields of change information are displayed only 
when a change has been made to the Desk Profile following its 
initial creation. 
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changed by.[changed'by] —An information-only field displaying 

the name of the last user who changed this Desk Profile. 

on.[changed'date] —An information-only field displaying the date on 

which the Desk Profile was changed. 


at [changedtime] —An information-only field displaying the time of 

the change. 

access [access'level] —The Access Level for the desk, a number be¬ 
tween 0 and 9. In order to access this desk, a user must have an 
Access Level equal to or greater than this level, or have this desk 
specified in his list of Explicit Access Desks. 


assign [assign a level] —The Assign Level for the desk, a number between 
0 and 9. In order to assign takes to this desk by entering the desk 
name in a take header, a user must have an Assign Level equal to or 
greater than this level, or have this desk specified in his list of Explicit 
Access Desks. 


Note: Naming a desk in a user’s list of Explicit Access Desks gives the 
user the authority to access all takes in that desk and to assign 
takes to it, provided he also has access to the basket(s) to which 
the takes are assigned. This list of desks therefore overrides both 
the Access and the Assign Levels of the user relative to the desk. 


list name [list] —The name of the default list style to be used for a 
directory of this desk if not specified in the directory prompt, or in the 
directory formats or directory commands specified in the user’s Pro¬ 
file. 


sorted (l, f, a or r) [order] —The method by which the takes assigned 
to this desk are to be sorted in a directory. Specify «l» for last in, first 
out (lifo); «f» for first in, first out (fifo); «a» for alphabetization (ascii 
sorting sequence); and «r» for reverse alphabetization. 

by (field name) [qfield'name] —Enter the name of the take header 
o-field to be used for sorting. For example, «story name» for an 
editorial header, or «account» for an advertising header. The hat 
character (« A ») is not required in this field. 


Basket Definition 


Like desks, baskets are defined by completing a Basket Profile form like 
the one illustrated in Figure A-1.2. Each form is a separate record in the file 
«$system.editor.basket». Different sites may have different basket file 
names and basket files for additional systems. 

The Basket Profile form name (conventional name is «basket») is used 
in accessing the record with the various levels of IcmdI [f] (Edit, Copy or 
Create Record with Form). 


In this discussion, to help identify a field’s literal name with its Q-field 
name (in structure «basket»), the name of the Q-field is given in brackets 
following the literal name: “Description [desc]». 
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Basket Profile of 


Description 


Created by 
Changed by 


on. at 

on. at 


Access _ Assign _ 

Type _ (X = spike, R = release, B = broadcast, 
P = pre-Q, Q = post-Q) 

List Name _ Transfer Alert Group _ 

Sorted (L, F, A or R) _ by (field name) _ 

Wire Entry Hours _ Extend Hours _ Day 

Default Transfer Desk _ 


Time 


Figure A-1.2. Basket Profile 


Basket Profile Field Descriptions 


basket profile of [name] —The name of the basket (12 characters). Any 
ascii character available on your printer may be used, including spe¬ 
cial characters. This permits the name to be printed in hardcopy lists 
and reports. All names are converted to uppercase. 

description [desc]—A required description of the use of the basket. This 
description is useful information in an index of baskets. 

created by . [created'by] —An information-only field displaying 

the name of the user who created the basket. 


on.[created'date]— An information-only field displaying the date on 

which the basket was created. 



AT 


... [created'Time] —An information-only field displaying the time of 
creation. 


Note: The following three fields of change information are displayed only 
when a change has been made to the Basket Profile following its 
initial creation. 


changed by.[changed BY] —An information-only field displaying 

the name of the last user who changed this Basket Profile. 


0N .; [changed'date]— An information-only field displaying the date on 

which the Basket Profile was changed. 

AT .[changed'time] An information-only field displaying the time of the 

change. 


access [access'level] —The Access Level for the basket, a number be¬ 
tween 0 and 9. In order to access this basket, a user must have an 
Access Level equal to or greater than this level, or have this basket 
specified in his list of Explicit Access Baskets. 

ASSIGN [assign'level]— The Assign Level for the basket, a number be¬ 
tween 0 and 9. In order to assign takes to this basket by entering the 
basket name in a take header or by executing the Transfer command 
(IcmdJQ □) and filling in the name of this basket as the destination, 
a user must have an Assign Level equal to or greater than this level', 
or have this basket specified in his list of Explicit Access Baskets. 


The destination baskets named in the User Profile for the Send, 
Spike and Release commands override the normally required Assign 
Levels for those baskets. They do not, however, grant the user Ac¬ 
cess to the baskets. 
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Whether users will have access to the baskets to which they have 
Sent or Released takes needs to be considered on an individual 
basis Although it need not be defined as such, it seems reasonable 
that users should have access, either implicitly or explicitly, to their 
own Spike baskets in order to retrieve takes spiked in error. 

Whether users will have access to the baskets to which they have 
Sent or Released takes needs to be considered on an individual 
basis Although it need not be defined as such, it seems reasonable 
that users should have access, either implicitly or explicitly, to their 
own Spike baskets in order to retrieve takes spiked in error. 

Note- Naming a basket in a user’s list of Explicit Access Baskets gives 
the user the authority to access all takes in that basket and to 
assign takes to it, provided he also has access to the desk(s) to 
which the takes are assigned. This list of baskets there ore 
rides both the Access and the Assign Levels of the user relative to 

the basket. 

tvdp (y = SPIKE R = RELEASE, B = BROADCAST, P = PRE-QUEUE, Q - 
post-queue) [BASKET'-TYPEl-This field determines how the basket 
may be used, specified as follows: 


i_i_ A r-j/'M-mal HaQkpt' for 




«x» —a spike basket; basket to which takes are 
sent when they are spiked. 

<<R>> —a release basket; basket to which stories 
are sent when they are released. 


«b» —A broadcast basket. 


«P» 


A pre-queue basket; basket to which 
5r ies are sent when they are transmitted 
mi'. Antinnoi va/iqpfr™ software. 


«Q» 


_A post-queue basket; basket to which 

stories are sent following transmission with 
Sll’s optional wisper™ software. 


sssssssss 

as such in its Basket Profile. 

ThP rasket'type field in the Basket Profile must be blank or contain 
I designating a valid basket type. The vpt control software 
performs mis validation, so it is not necessary to use content checks 
w tho fipid in the form. 


This special control feature does not allow a user to do the following: 

1 Send or otherwise transfer a story to a basket tagged as a spike or 
release basket. The appropriate command must be used. This 
provides tighter control over copy flow. 
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2.Spike a story to a basket which is not tagged as a spike basket. The 
user’s Spike Basket must be specified in the User Profile and the 
spike basket must be valid. 

3. Release a story to a basket which is not tagged as a release basket. 

4. Transmit a story by transferring it to a pre-queue basket. The appropriate 

command must be used. This prevents unauthorized transmission of 
stories. 

LIST NAME [LIST]— The name of the default list style to be used for a 
directory of this basket if not specified in the directory prompt, or in 
the directory formats or directory commands specified in the user’s 
Profile. 

transfer alert group [msg'group] —The user group (or single user) to 
be alerted whenever a take enters this basket. When a Transfer Alert 
Message is broadcast, it is displayed on the status line of the vdts of 
all members of the message group who are currently signed-on and 
who have not disabled message notification with Icmdi Q [m]). 

sorted (l, f, a or r) [order] —The method by which the takes assigned to 
this basket are to be sorted in a directory. Specify «l» for last in, first 
out (lifo); «f» for first in, first out (fifo); «a» for alphabetization (ascii 
sorting sequence); and «r» for reverse alphabetization. 

by (field name) [qfield'name] —Enter the name of the take header 
Q-field to be used for sorting. The hat character («"») is not required. 

wire entry hours [wire entry'hours] —The number of hours (maxi¬ 
mum is 32767) to be added to the time of entry of wire takes for the 
computation of the expiration date and time. This field applies only to 
baskets to which wire takes are routed and only when wire takes are 
entering the system. If this field is not filled in and a wire story is 
routed to this basket, extend hours will be used instead. 

extend hours [extend'hours] —The number of hours (maximum is 
32767) to be added to the current date and time to recompute the 
expiration time whenever a take in this basket is referenced. This field 
applies to the original creation of local takes, and all Local or Wire 
takes which are edited, transferred, justified, “Spellbound,” proofed, 
output or spiked. Any of these functions implies interest on the part of 
the user, and this factor extends or decreases the currently-assigned 
expiration date and time. Specifying this value as zero (0) is the 
equivalent of “’til forbid”; all takes in the basket will be permanent (i.e., 
there will be no expiration date and time). 

day [cycle'day] —The day of the week on which the weekly cycle, if any, 
for this basket ends. Cycle Day is used to determine an actual base 
date for copy. Zero (0) or blank indicates no specification for cycle 
day. The days of the week count from 1 through 7 for Sunday through 
Saturday. If «day» is not specified (zero or blank), weekly cycles are 
not used to compute expiration dates. 

time [cycle'time] —The hour of the day (0-23) and minute (1-59) at which 
the weekly cycle ends. 3:59 p.m. is expressed as «15:59». If a time is 
not specified, the first minute of the Cycle Day (00:01) is assumed. 
This field is ignored if «day» is not specified. 
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default transfer desk [desk] —The desk to which the story is to be 
assigned if none is specified when the story is transferred to another 
basket. 

Editorial Expiration Date Computations 

An understanding of how expiration dates are computed is essential to 
making valid decisions in specifying the “Wire Entry Hours,” “Extend 
Hours” and Cycle “Day” and “Time” fields of the Basket Profile. The expira¬ 
tion date on a take determines when that take (and any previous Oops or 
Audit copies) will be subject to purging from the system by the scheduled 
purge process. The following are the objectives for the methods used: 

• To make the computation of expiration dates responsive to user interac¬ 
tion with the data base. 

• To allow expiration factors to be assigned for each individual basket and 
to have the computation of the expiration date follow the movement of a 
take from basket to basket as a valid expression of interest (or disinter¬ 
est) in the take. 

• To update the expiration date based on the time the take is referenced 
as opposed to when it is entered. 

• To maintain a distinction between wire service copy and local copy in 
the assignment of expiration dates. 

• To give the user the facility for expressing a weekly cycle for a basket 
with the date and time the cycle changes. 

• To preserve copy in an editorial system until its publication date has 
passed. 

The following rules are used in computing expiration dates. Note that 
when a publication date is assigned to a story it replaces the cycle day 
and time, if any, and the expiration date is automatically recomputed. This 
prevents the take from expiring prior to its publication. If the publication 
date of a take is changed, the expiration date is adjusted accordingly. 

For Incoming Wire Takes 

If only wire entry hours is specified: 

expires = date/time of entry + wire entry hours. 

If only extend hours is specified: 

expires = date/time of entry + extend hours. 

If cycle day/time and wire entry hours are specified: 
expires = next cycle date/time + wire entry hours. 

If cycle day/time and no wire entry hours are specified: 
expires = next cycle date/time + extend hours. 

For Takes Being Created, Edited, Justified, 

“Spellbound,” Sent, Transferred, Output or Spiked 

If a publication date has been assigned: 

expires = publication date + extend hours. 

If extend hours is specified but no cycle day/time has been specified: 

expires = current date/time + extend hours. 

If cycle day/time is specified: 

expires = next cycle date/time + extend hours. 
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Note that an Extend Hours value is always present in a Basket Profile— 
zero (forever) or the number of hours entered. 

Expiration Date Override 

It is generally recommended that the basket-controlled expiration com¬ 
putations be used exclusively and that the expiration date and time fields 
(Q-fields «expiration"date» and «expiration , 'time» in the header and 
cheader structures) be displayed as information-only fields in make head¬ 
ers. 

A possible exception is the case of personal baskets. If, for example, a 
user’s personal basket is defined with an extend hours factor of 48, takes 
will remain in that basket for two days before expiring. However, the user 
may wish to alter the expiration date (without moving the take to another 
basket) in order to hold on to some stories for a longer period. This 
capability may be selectively given to users by inserting the expiration date 
and time fields as variable fields in their header forms. 

When a user overrides the computed expiration information, the header 
status field «expire"override» is flagged with an asterisk so that this 
condition may be observable in take headers and lists of takes. 

Personal baskets may also, at your volition, be permanent baskets with 
an extend hours factor of 0 (zero). If this be the case, the user may 
deliberately spike stories to get rid of them and there is probably no need 
for him to have access to the expiration fields. 

What this boils down to is a simple decision on your part: Do you wish to 
centrally maintain absolute control over the expiration of stories through 
your basket definitions, do you wish to give this control to individual users, 
or do you wish a combination of the two methods? 

Personal Baskets 

Although it is not a system requirement, it is good practice for a personal 
basket to be defined for each user with the same name as the user. This 
basket is normally reserved for personal takes. As a general practice 
“working baskets” containing copy being readied for publishing should be 
separate from personal baskets so that they may be shared by more than 
one user. 

For it to be truly personal, a user’s personal basket should have an 
Access Level of «9» and an Assign Level that is low enough to permit 
other users to assign takes to it. This means that most users may not 
define their own personal baskets. When the User Profile is created for the 
user, the name of the user’s personal basket should be entered as one of 
the Explicit Access Baskets (the basket must have been defined first). As a 
result, only the user has access rights to his own basket (aside from those 
few level 9 users), although other users at the basket’s Assign Level or 
above may send or transfer takes to the basket. Users may ensure priva¬ 
cy, even from higher level users, by flagging takes as “Private” if the 
“Private/Read Only/Copies Only” field is displayed in their take header 
forms. 
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Spike Baskets 

A user’s ability to spike takes is solely dependent on whether or not the 
name of a Spike Basket is specified in the user’s Profile and on whether 
that basket is properly flagged as a spike basket. If it is not, the message 
“Outside your jurisdiction” is displayed on the status line (as with all author¬ 
ity violations) when the user executes IcmdI IkI. 

In accordance with its normal meaning, a spike basket should have a 
low Extend Hours value specified for it. The lowest possible value for a 
spike basket is «1» (with «0» it is a permanent basket). Therefore, takes 
are always recoverable for at least one hour after they have been spiked. 
You may wish to increase this time to 2 or 3 hours, to an entire shift, or to 
24 hours so spiked takes can be recovered the next day. 

Other considerations are how many spike baskets you will have in the 
system and who will have access to them. Depending on how you wish to 
use them, there may be one spike basket for an entire system, one for 
each department, or one for each user. So that users may recover takes 
they spike, normally they should have access to their spike baskets, either 
implicitly through assigning a very low Access Level to the basket, or 
explicitly by naming the basket in the user's list of Explicit Access Baskets. 
You may also elect to deny users access to their spike baskets. 

Actually the Spike command is just another form of the Send command 
(except that its completion message is different) and spike baskets are just 
baskets that happen to significantly lower the expiration date and time of 
takes entering them. The difference between “send” and “spike” is there¬ 
fore dependent on the definition of the destination basket. The Spike 
Basket in the User Profile, however, should be treated as an authority, 
whereas the Send Basket might be treated as a default so a user may 
change it. 

For some users, you may choose to use the spike basket as an alter¬ 
nate “send” basket, instead of as a death row for copy. This depends 
entirely on the Extend Hours factor for the basket. 

Creating, Copying, Editing and Deleting 
Desk and Basket Profiles 

A user must have Desk Define authority to create and alter Desk Pro¬ 
files, and Basket Define authority to create and edit Basket Profiles. Addi¬ 
tionally, a user may not define (create, edit, delete) a desk or basket that 
has Access or Assign Levels greater than his own. 

While defining baskets and desks it is most efficient to work from an 
Index of «baskets» or «desks» with a list style that displays the record 
fields in which you are most interested—perhaps the name, description, 
list name, Access and Assign Levels, expiration factors for baskets, etc. 
This allows you to copy a filled-in record that most closely matches the 
new record you wish to create, thereby speeding up basket and desk 
definition considerably. 

Desk and Basket Profiles, User Profiles and all other types of records 
which may be acc essed with a form, are created, copied and edited with 
the three levels of |cmd| [f], and are deleted with IcmdI (T[ [kJ as illustrated 
in the following discussion. 
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Create a record with [cmdI □ 0. If the cursor is not on an item in a list 
of records ( IcmdI 0, List Name «baskets») you will be supplied with a 
blank prompt. If the cursor is pointing at a record, the form name (record 
type) will be filled in for you: 

Form BASKET _ Path _ (Create record) 


Key 


Fill in the name of the new record in the «Key» field and press [return]. 
(Ignore the «Path» field. It is for specifying unique paths for records in 
data processing files and does not apply in normal uses of this com¬ 
mand for System/55.) The blank record form will be displayed with the 
message “Creating record” on the status line. Fill in the form and exe¬ 
cute another command ( IcmdI ITT 0 to return to your index), causin g the 
record to be filed. If you decide not to file it, you must execute Icmd| |T1. 


• Copy a record with IcmdI □ 0. If the cursor is pointing at an item in a 
list of records, the indicated record will be copied and displayed with the 
name field blank. The message “Copying record” will be displayed on 
the status line. If the cursor is not on a list item, you will be supplied with 
a blank prompt. You must supply a form name in the «Form» field and a 
record name in the «Key» field to indicate which unique record is to be 
copied. For example: 

Form BASKET _ Path _ (Copy record) 

Key NATIONAL _ 

Press IcmdI and a copy of the record will be displayed, without the new 
record name which you must supply. Fill in the form and file it. 


Edit a record with IcmdI If], If the cursor is pointing at an item in a list of 
records, the indicated record will displayed immediately. The message 
“Editing record” will be displayed on the status line. You may make the 
desired changes and then refile it. If the cursor is not on a list item, you 
will be supplied with a blank prompt: 


Form _ Path _ (Change record) 

Key _ 


You must supply a form name in the «Form» field. If you do not type a 
unique record name in the «Key» field, the record, if any, bearing your 
user name is assumed (e.g., your personal basket); otherwise, the 
record whose name you type will be displayed for editing. 

• Delete a record with IcmdI [7] 0. To delete baskets and desks, the 
following must be true: 1) you must have Purge authority; 2) you must 
have Desk Define or Basket Define authority, as appropriate; and 3) 
your Access Level (in your User Profile) must be equal to or greater than 
that of the basket or desk you wish to delete. 

If the cursor is pointing at an item in a list of records, the indicated record 
will be displayed immediately with the following blinking message on the 
status line: “Record will be deleted.” To complete the deletion, execute 
any command which implies filing of the record (e. g., ret urn to the Index 
to note its absence); to abort the deletion, execute IcmdI IT]. If the cursor 
is not pointing at an item in a list, a prompt is displayed: 


Form 
Key _ 


Path 


(Delete record) 


You must supply a form name in the «Form» field and a unique record 
name in the «Key» field. The record will be displayed with a warning 
message as described above. 
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Editorial Uses of Baskets and Desks 

The concept of baskets and desks in the newsroom is subjective. The 
use of these System/55 organizational elements is so flexible—there are 
so few restrictions placed on them—that they can be made to conform to 
any structural picture (real or proposed) of your newspaper’s processing of 
news copy. 

The use of baskets is required by the system. Every take in an editorial 
system must be in a basket. This is the only requirement. 

Desks, on the other hand, are optional. A story may or may not be 
assigned to a desk. Desks are an added convenience for the organization 
of text. At your option they may be ignored entirely. 

Objectives 

The major objectives, and therefore considerations, in defining desks 
and baskets are to: 

1. Make it easy for users to get at the information they need to do their 
jobs and, further, to make takes of general interest available to as many 
users as possible. 

2. Limit access to critical information that is essential to system operation 
and/or the production of the newspaper. 

3. Delineate areas of responsibility, interest and confidentiality throughout 
the newsroom, production, operations and administrative areas. 

4. Establish regulated paths of copy flow through the system, predeter¬ 
mining the relationships between users and text. 

The meaning of a desk or basket is not complete, or even apparent in 
some cases, until the relationships of system users to it have been de¬ 
fined. 

Definitions and Concepts 

Since the subject of text organization is purely abstract, your under¬ 
standing may be enhanced by the following scenario: 

Imagine that the text file—all of the stories in the system—is a huge, 
open newsroom; that “desks” are reporters’ and editors’ desks in the 
newsroom; that “baskets” are in-, out- and work-baskets on the desks; and 
that the baskets contain Teletype output and typewritten, marked-up 
stories. Unwanted stories are impaled on steel spikes (“spike” baskets), 
and personal items are put away in drawers (“personal” baskets). That’s 
your old newsroom, more or less, isn’t it? 

That is also the way text is organized in System/55, in desks and 
baskets. 

Now imagine that all but two or three desks are carted away. All of the 
baskets are stacked on those few remaining desks and reporters, editors 
and copy people are competing for space trying to identify them. It’s like 
the first day of a sale at your favorite department store. 

Finally, the remaining desks are hauled out the door. Now all of the 
baskets are scattered about the floor and personnel are consistently for¬ 
getting where to find them. 

The moral of this story is that “desks” give employees a home base, a 
community (department) within which to work, a means of organizing their 
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work in cooperation with their co-workers, and a sense of identity and 
continuity. 

Desks and baskets are the user’s link with text in the system. 


“Desk” Options 

Three possible interpretations of “desk” are introduced below. In each 
method, baskets contain stories of similar subject matter, as defined by 
users. 


DESK Ai 


DESK B j 


BASKET 1 

BASKET 2 

BASKET 3 

BASKET 4 

BASKET 5 

BASKET 6 

BASKET 7 

BASKET 8 

BASKET 9 

BASKET 10 

BASKET 11 

BASKET 12 

BASKET 13 

BASKET 14 


DESK C 


Figure A-1.3. Overlapping of Desks and Baskets. 


• Method 1 —No desks. Only baskets are used. 

• Method 2 — Desks are used to separate stories by type, like «wire», 

«local» and «production». 


• Method 3 — Desks more specifically delineate separate departments or 
groupings of roles in the production and operation of the 
newspaper. 

Method 1 provides the simplest form of text management. It may be a 
good approach when there are a limited number of areas of responsibility 
and a small number of baskets. The disadvantage of this method is that it 
lacks the desk’s facility for subdividing the text file. There are fewer meth¬ 
ods for accessing takes. Depending on the application of the system as a 
whole, this method would probably prove awkward with a large text file 
accessed by many users. 


Method 2 enables separate directories of each broad category of take 
defined by the limited number of desks. This is helpful, but it still limits a 
user’s ability to observe more specific cross-sections of the text file. 

Method 3 is more complex to define, but its advantages are numerous. 
In this approach, the text file is divided into as many desks as are required 
to separate user responsibilities. This not only makes a very large text file 
more manageable, but it provides an added security tool (the desk’s 
Access and Assign Levels) and additional methods of accessing stories. 


Very generally, the scope of a desk is broad and that of a basket is 
narrow. Baskets and desks operate independently as you define them. 
They may overlap with respect to individual takes. This is illustrated in 
Figure A-1.3. 
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A single story may be assigned to only one basket and to one desk. 
Stories in a basket may all belong to the same desk or to different desks 
(or to none). Observe that all stories in Baskets 1 through 4 are assigned 
to Desk A, and that all stories in Baskets 10-14 belong to Desk B. Baskets 
5-7, however, contain some stories assigned to Desk A and some as¬ 
signed to Desk C. Similarly, Baskets 8 and 9 contain stories of both Desks 
B and C. 

A list follows of possible desks for the editorial system of a newspaper. It 
is separated into general desks—those with system-wide uses and those 
which are system- or newspaper-management oriented—and editorial 
desks applying only in the newsroom. This list is certainly not complete; it 
is offered only as an illustration. 

General Desks: 

admin —Administrative. Accessible to management staff. Certain 
baskets (those containing memos to all employees, for 
instance) may be made available as read-only system 
wide. 

word proc —Word processing. Accessible to word processing person¬ 
nel and accessible to, or assignable by all users on an 
as-needed basis. 

DATA PROC —Data processing. Accessible only to data processing 
personnel. 


PRODUCTION 

—Accessible only to production personnel. 


OPERATIONS 

—Accessible to operations and maintenance 

personnel. 

Editorial Desks: 



ADVISORIES 

STATE 

AMUSEMENT 

LIFESTYLE 

BULLETINS 

REGIONAL 

BUSINESS 

SPORTS 

WORLD 

CITY 

FEATURES 

TRAVEL 

WASHINGTON 

ADVANCE 

HOME 

WEATHER 

NATIONAL 





Each of these editorial desks would normally contain stories assigned 
to: 

• the incoming wire baskets relating to that area of interest, 

• the personal baskets of the users belonging (defaulting) to that desk, 

• the “work baskets” of the reporters and editors belonging to the desk, 
and 

• the release basket(s) for the desk which would normally be accessible 
only to senior editors and production personnel. 

A desk directory of «travel» therefore lists a specific cross-section of 
the text file, including all stories in all stages of processing. A travel editor 
isn’t interested, of course, in stories in the «sports» desk. 

Bulletins and Advisories 

Observe that in this sample system all advisories are routed to the 
«advisories» desk and bulletins to the «bulletins» desk. On an individu¬ 
al take basis, however, advisories and bulletins may be routed to separate 
askets based on category; i.e., international bulletins/advisories and gen- 
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eral news bulletins/advisories would all be sent to separate baskets. This 
results in a select group of editors being alerted (the basket’s Transfer 
Alert Group) when an advisory or bulletin of interest to them enters its 
respective basket. A directory of desk «bulletins» will list all bulletins, 
whereas a directory of basket «intl bull» will list only the bulletins of 
interest to international news editors. 

Establishing a Hierarchy of Access 
and Assign Levels for Your System 

Before beginning to define Access and Assign Levels for desks, baskets 
and users it is important to establish the general meanings that the individ¬ 
ual levels will have for your system. Randomly assigning numbers will 
ultimately result in confusion and access being allowed or denied where it 
is not desired. A scheme for Access Levels might be as follows: 

access level 9—system management personnel only 

access level 8—production personnel only 

access level 7—senior editors only 

access level 5—editors 

access level 4—editors 

access level 3—editors 

access level 2—reporters 

access level 1 — reporters 

access level o—beginning users 

Assign levels may be reflected in the same scheme, with users normally 
being able to assign to higher levels of basket and desk than they may 
access. This is illustrated in the example under the next sub-heading, 
“Story Routing.” In the next section, you will see how User Levels may also 
follow this scheme, each level of which reflects a user’s authority and/or 
expertise. 

Story Routing 

An important factor to be considered in the organization of users and 
baskets is the routing of stories through the system—from input to output. 
Input may be from the wire services, from local reporters or from remote 
reporters, but the destination is always the same: the desk’s release 
basket. 

Figure A-1.4, on the following page, illustrates the control that may be 
exerted over copy flow within a particular desk, in this case the «busi- 
ness» desk, through careful manipulation of the Access and Assign levels 
of both users and baskets. 
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Figure A-1.4. Story Routing Within the Business Desk, Controlled With Access and Assign Levels. 

For simplicity, this example deals with only three baskets and two users 
which are representative of the larger picture. Basket « financial^ is the 
receiving basket for all incoming business/financial non-tabular wire takes. 
Two users, John and Frank, may access the stories in this basket and edit 
them in their own work baskets (not shown, but represented by their user 
names). Edited stories are then sent to the business basket for final 
approval and/or page makeup (by Frank), and completed pages are finally 
released to «business sec», this desk’s release basket. This continuous 
and regulated flow of information, indicated by the large vertical arrows, 
may not be reversed. 


The default desk for John and Frank (specified in their User Profiles) is 
«business» and all stories entering the «financial» basket are assigned 
to that desk. At any given time a directory of the «business» desk re¬ 
quested by John or Frank will list all stories in all of the baskets to which 
that user has access. In his directory of the desk, John will only see stories 
in the financial basket and in his personal basket. Frank will see stories 
assigned to the financial basket, to the business basket and to his 
personal basket. In other words, a desk directory gives Frank a broad 
picture (excluding the release basket « business sec» to which he does 
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not have access), but it gives John a fairly narrow one. Both users see only 
the stories that concern them. 

Basket financial has an Access Level of 4 and an Assign Level of 9. 
Both John (Access Level 5) and Frank (Access Level 7) may transfer 
stories from this basket into their own baskets, but neither may transfer 
stories to basket financial. 


Both John and Frank may transfer stories to basket business (actually 
this could be John’s “send” basket, making it unnecessary for his Assign 
Level to permit transferring), but only Frank may access stories in that 
basket. John edits stories and places them in the business basket; Frank 
makes up the pages and/or approves single stories and releases them to 
business sec, a basket which is accessible only to production personnel. 
John may not transfer stories to business sec because that basket’s 
Assign Level is higher than his own. 

If John wants to get a story back from the business basket for further 
editing, he must have Frank transfer it to his basket; he does not have the 
authority to do that himself. If Frank wants to retrieve a story he has 
released, he must have a production user of higher authority transfer it 
back to the business basket. 


This process ensures that stories may not be filmed and subsequently 
reedited without the knowledge of production personnel. 
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SECTION A-2 

User Definition 

Once the major desks and baskets have been defined, you may define 
the users of the system. Every desk and basket specified by name in a 
User Profile must already have been defined. 

User Files 

Each system user is defined by completing a User Profile form for that 
person. Each form is a separate record in the user file, and there is a 
separate user file for each system. 

For simplicity, a common structure— «user>rofile»— is used for all 
user files regardless of their application, advertising or editorial. This struc¬ 
ture is used for creating forms (User Profile, User Defaults) and lists. The 
User Profile form name «user profile» is used in accessing the record 
with the various levels of IcmdI [f] (Edit, Copy or Create Record with Form). 
The User Defaults form is accessed by users with IcmdI fuT: the required 
name of this form, since it is accessed directly by a user command, is 

«USER DEFAULT”. 


User Profiles 

The structure «user"profile» contains over 140 Q-fields. Most fields 
apply to both editorial and advertising profiles, but some apply to only one 
kind of system user. Some other information-only fields—such as «tan- 
dem'group», «tandem"user>>, the date and time at which the user last 
signed off, who last changed the user’s password and when—tend to 
clutter a User Profile and are better used in designing lists of users. 

Standard User Profile forms are provided for each of your systems. You 
may make minor modifications to them, but you are urged to examine the 
importance of each field first. 

Conventions Used in Field Descriptions 

The fields in Figure A-2.1 are described on the succeeding pages. In the 
User Profile forms the fields are assigned literal names to clarify their 
meanings, and those are the names by which the fields are known in this 
discussion. To help identify a field’s literal name with its Q-field name (in 
structure «user>rofile»), the name of the Q-field is given in brackets 
following the literal name: «story release [a"story'rel]». 

User Profile Field Descriptions 

user profile for [name] —The name of this user. The «author» and 
the “Original USER” (header record fields) of all takes created by this 
user. Up to 12 characters. Any displayable character may be used. 
Case is unimportant: all characters are converted to uppercase. If 
special characters are used, they should be limited to those ascii 
characters engraved on the terminal’s keys. If other special charac¬ 
ters are used, the name may not be printed in a list or a report. This 
caution applies to any field with an unlimited character set. 
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full name [desc] —A required description of this user. Up to 30 alphanu¬ 
meric characters. Case is unique. 

dept [department] —Can be used to group users for the purposes of 
generating reports. 


output [out"dev] —The 6-character device name used to automatically 
fill in the “device” field (same field name in header structure) in the 
headers of all takes created by this user. For example, «aps». For 
wire takes, this header field is filled in by the wire routing software. 


( ) [ouT'loc] —The 8-character location name of the physical 

sub-device to be supplied (same field name in header structure) to 
the headers of all takes created by this user. For example, «aps.i ». 


User Profile for 

Full Name 

Dept. 

Outnut ( 

) Proof 

Header 

STYL 

Glossary 

Deadline Long lines 

User Group 

Filing Group 

Basket 

Send 

Desk 

Spike 

Release 

Xmit 


Baskets 


Desks 


Access Level _ Assign Level _ User Level _ Priority _ 
Read Level _ Write Level _ List Level _ Form Level _ 


Command Authorities 

User Modify _ User Create 
Desk Define _ Bask Define 
Page release _ Edit at all 
Proof _ Output 

Wire Forward _ Mult VDTs 
Glossary def _ SDK def 
Remote user _ Bust Story 


User Delete _ Password 
Page Assign _ Story rel 
Edit Text _ Justify 
Purge _ Cmd Interp. 

Utility _ Story Dup. 
Input Ctrl _ Output Ctrl 
Send Message _ Spell 


Figure A-2.1. User Profile. 


proof [proof key] Determines which Proof Key Record is to be used. For 
example, if a user has printer entered in the proof field all her proof 
requests ( IcmdI [p]) and hardcopies of lists ( IcmdI [)fl) will be directed 
to the device specified in the Proof Key Record with printer entered 
in the key field. 


header [header'form] —The 12-character name of the header form to 
be used for displaying all stories created or accessed by this user. 
The user cannot view stories if a header name is not specified in this 
field. The same header form may be used by different groups of 
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users, or forms may be individualized for specific users. The form 
controls which fields the user may see and/or change. See “Header 
Form Security” later in this section. 


styl [styl] —The default styl typesetting procedure for this user. This 
name is written in the “styl” field in the headers of all takes created 
by this user and called automatically at the beginning of the take. 


glossary [glossary] —The name of the udk glossary to be referenced 
for this user. A glossary contains definitions for User Defined Keys— 
functional or editing procedures which are accessed with single key¬ 
strokes—for each of the displayable characters on the keyboard (over 
200), although not all keys need be defined for a glossary. The 
number of glossaries of udks that may be defined is unlimited. Each 
user may have his own glossary or, more practically, a single glossary 
may have a number of users. 


deadline [deadline] —This user’s deadline time in hours of the 24-hour 
clock. The deadline frees the user from having to specify a publication 
date for page directories. It is also used to arrive at a publication date 
for created takes. If the user’s deadline is “18:00” and the current time 
is 17:30, today’s date (“today”) is assumed; if the current time is 
18:15, (past the user’s deadline), tomorrow’s date (“tomorrow”) is 
assumed. If no deadline time is specified, today’s date is assumed. 


long lines [long'Tines] —The number of lines to be displayed for each 
take in a long directory ( IcmdI [Q) requested by this user. A value up 
to 10 may be specified to be automatically inserted in the “Lines” field 
of the long directory prompt. If this field in the User Profile is left blank, 
the Long Directory command assumes 5 lines. 


user group [vdt'group] —The vdt group, if any, to which this user is 
assigned. The user may not sign-on to a vdt assigned to a group 
other than his own. 


filing group [filing'group] —(Used by Sll’s optional wisper™ soft¬ 
ware). The filing group provides security by preventing users from 
transmitting copy ( IcmdI □ [3) to any destination they wish. When a 
filing group is specified here, the user will only be able to transmit 
copy to destinations which have that filing group specified in the 
filing group of the Destination Group record. 


send [send'basket] —The name of the basket to which takes are trans¬ 
ferred when this user executes the Send command— IcmdI 0. The 
basket must have been previously defined. If this field is blank, the 
user is supplied with a prompt—the equivalent of executing the 
Transfer command ( IcmdI Q [!])• When a take is sent or transferred 
to another basket, the desk assignment (if any) of the story is unaf- 
' fected unless a desk is specified in the desk field. 


desk [send'desk] —The name of the desk (if any) to which takes are 
transferred when this user executes the Send command— IcmdI [t]. 
The desk must have been previously defined. 


spike [spike"basket] —Enables the user to execute the Spike com¬ 
mand— IcmdI \k\ — by entering in this field the name of the basket to 
which takes will be transferred. The basket must have been previous¬ 
ly defined. If this field is blank, the user is unable to spike stories. This 
field is therefore an authority and should be excluded from the user 
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defaults (see “User Defaults” later in this section). Spiking a take does 
not change the desk to which it is assigned. 

The spike function allows an editor to quickly rid a basket or desk of 
stories he doesn’t wish to use. The receiving basket would normally 
have a short Extend Hours factor to allow the story to be purged in the 
next delete cycle. Until purging takes place, however, the story may 
be retrieved from the Spike basket. There may be one Spike basket 
for an entire system, one per desk, or one per user. 

release [release'basket] —Enables the user to execute the Release 
Story command— [cmdI □ (U— by entering in this field the name of 
the basket to which stories will be transferred. To be released, a story 
must be assigned a publication date and page name or number (see 
Page Assign, Story Release, and Page Release authorities). When a 
story is released for publication, its Release Status is changed to «R» 
(allowing this status to be displayed in a directory or the desk). 
Releasing does not alter the story’s desk assignment. The basket 
named in this field must have been previously defined. If this field is 
blank, the user is unable to release stories. This field is an authority 
and should be excluded from the user defaults (see “User Defaults,” 
later in this section). 

xmit [xmiT'basket] —When the Transmit command— Icmd| □ [T]— is ex¬ 
ecuted, the original of the transmitted story is moved to this basket. 

baskets [b"read"only"i / default"bask"i through 

b"read"only"i 2 / default" bask" 1 2 ]—A list of baskets to which this 
user has explicit access and also a convenient list of baskets for the 
Basket/Desk list ( Icmdi [§]). Baskets named in this list override the 
normal Access and Assign (except for read-only baskets) Levels 
required for their use by this particular user. Fields for 12 baskets are 
provided in the editorial User Profile. 

The first field of each item is a read-only flag; the second field is a 
basket name which must already exist. Enter an «r» in the read-only 
field if a basket is to be read-only to this user. A user may only read 
takes assigned to a read-only basket; he may not edit takes in that 
basket or transfer takes into or out of the basket. A user with 
read-only access may, however, copy takes in the basket as long as 
he assigns the copies to another basket to which he has full (not 
read-only) access. 

The first basket in the list that is not flagged as read-only is automati¬ 
cally entered in the «basket» field of the headers of all takes created 
by this user. (It need not be the user’s personal basket.) 

Since this list is normally (not necessarily for a classified system) 
displayed with the User Defaults and because certain users may have 
access to their own complete User Profiles or those of other users, 
restrictions are imposed on the entering of basket names: 

1. A user may rearrange the basket names (to cause another name 
to be used as the default in a take header) and enter the name of 
new baskets falling within the user’s range of Access and Assign 
Levels. 

2. Another user changing this User Profile—with user Modify author¬ 
ity and a User Level equal to or greater than that of this profile— 
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may enter the name of baskets falling within his levels of authority, either 
by being at or below the required Access and Assign Levels himself or by 
having the name(s) in his own list of baskets. 


3. A user may not grant authorities, to himself or others, which he 
does not himself possess. Therefore, if a basket name which is an 
explicit override (granted by a higher level user than the current 
user) is deleted and the profile is filed (changed), the name may 
not be reentered; a user of greater authority must reinstate it. 

desks [d~read“only"i / default'desk'i through 

d"read”only’'i 2 / DEFAULrDESK“i2— A list of desks to which this 
user has exp licit^ ac cess and a convenient list of desks for the Bas¬ 
ket/Desk list ( |cmd| FbI ). Like the basket list, Desks in this list override 
the normal Access and Assign (except for read-only desks) Levels 
required for their use by this particular user. Fields for 8 desks are 
provided in the editorial User Profile. 

The first desk in the list that is not flagged as read only is automatical¬ 
ly entered in the «desk» field of the headers of all takes created by 
this user. 


The restrictions described above for the entry of basket names also 
apply to desks. 


Authority Levels 

The following 8 levels are implicit authorities within whose ranges the 
user’s activity is restricted. Each may be specified with a number in the 
range of 0 through 9, except for Priority which is limited to 0 through 6. In 
all cases, a user may not assign a level to other users that is greater than 
his own respective level; and if he lowers a level of his own, only a user 
with a higher level (with other appropriate authorities) may reinstate it. 


ACCESS LEVEL [access'level]— (0-9) In order to access a take for editing, 
reading or copying, the user must have an Access Level which is 
equal to or greater than that of the desk or basket containing the 
story, or have that specific desk or basket in his explicit access lists. 
When a directory is requested, takes referencing desks and baskets 
outside the user’s range of authorities will not be displayed. 

assign level [assign'level]— (0-9) In order to assign a story or ad to a 
basket or a desk (transfer it or type the name in the header), the user 
must have an Assign Level equal to or greater than that of the 
receiving desk and/or basket, or have that specific desk or basket in 
his explicit access lists. The explicitly named Send, Spike, and Re¬ 
lease baskets override the user’s Assign Level, unless these basket 
designations are changeable by the user by being included in the 
User Default form, in which case the user may only specify baskets 
within his own jurisdiction. 


Note: 



When a take is first assigned to a basket or desk, the basket and/or 
desk Access and Assign Levels are recorded in the take’s header 
record. (This saves considerable time in filtering directories.) There¬ 
fore, if these levels in a Basket or Desk Profile are changed while 
there are takes assigned to that basket or desk, the levels recorded 
in the take headers will not change and it is possible that they will 
be higher or lower than those of the basket/desk. If the Access 
Level of a basket is lowered, for instance, new users of the basket 
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may not have access to takes previously (to the change) assigned 
to that basket. Such a situation (also a change in the sort method) 
may be rectified by having an authorized user Send all the takes to 
another basket and then (by changing his default Send basket) 
Send them all back to the original basket. If there are many takes in 
the basket, a udk may be defined to do this quickly. Mass desk 
transfers of takes can also be accomplished with a udk. 

user level [user'level] —(0-9) This level ranks a user among all users 
in terms of knowledge of the system, general authority and responsi¬ 
bility. A user’s level is purely relative to the levels of other users. An 
identical “knowledge/responsibility” scheme to that suggested for Ac¬ 
cess Levels in Section A-1 may be applied to User Levels: 
user level 9 —system management personnel 
user level 8—production personnel 
USER LEVEL 7—senior editors 
user level 5—editors 
user level 4— editors 
user level 3—editors 
user level 2—reporters 
user level i —reporters 
user level o—beginning users 

The User Level is applied in two ways: 

1. It controls the definition of forms and lists. In order to edit or delete 
a form or list, a user must have a User Level that is equal to or 
greater than the Change Level of the form or list. This is shown 
under User Level” in Table A-2.1. Additionally, a user may not 
assign a Change Level to a form or list that is greater than his own 
User Level. The important task of maintaining the system’s forms 
and lists may thus be restricted by User Level to the more knowl¬ 
edgeable users. The most important forms and lists should be 
given the highest Change Levels. User, Basket and Desk Profile 
forms, and User Default forms should all be given a Change Level 
of 9. 

2. It controls the definition of users. In order to modify, delete or 
change the password of another user, a user must have a User 
Level that is equal to or greater than that specified in the User 
Profile being accessed. A user may not assign a User Level to 
another user, in creating or modifying, that is greater than his own. 
Specific authorities, as described below, are required for all of 
these tasks. 

priority [priority] (0-6) The selection priority of this user with regard to 
the use of system processes such as justification, headfitting, Spell¬ 
binder, proofing, output, report printing, etc. Higher priority users are 
serviced before lower priority users. If desired, the system manag¬ 
ers) and managing editor(s) may be given a priority level of 5. All 
other users should be started at 0 (zero) and raised as required. 
Priority level 6 should be reserved for truly urgent projects such as 
processing election results; it may be given to a user on a temporary 
basis. Priority levels are not absolute; they are relative to the priorities 
of other users and apply only during peak load periods (if jobs are 
queued for processing, the jobs submitted by higher priority users are 
processed first regardless of the order in which they entered the 
queue). 
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read level [read"level] —(0-9) The level of information-only 
Q-field (unchangeable data) a user may insert in a form (with pro¬ 
gram «fgen») or list (with program «lgen») or report (with program 
«rgen»). Q-fields are assigned Read Levels with program «Q». A 
user may only insert info-only fields that have Read Levels at or 
below his own Read Level. This is shown in Table A-2.1 under 
“Read Level” on the following page. 


Table A-2.1 


Use of Authority Levels in Defining 
and Accessing Forms and Lists 


Form/List 

Form/List 

form/list 

q-field 

Q-field 

Definition: 

Access Level 

Change Level 

Read Level 

Write Level 

User Level. 

Read Level _ 

Write Level _ 

Form/List Use: 

List Level. 

Form Level _ 

^ for « cmd d» 
and « cmd x» 

^ for « cmd f» 

> 

^ for info-only 
fields in lists 
and forms 

^ for variable 
fields in forms 


In order to create, edit or delete forms or lists, a user must have the 
appropriate program in his List of Available Processes and/or he must 
have Command Interpreter authority. 


write level [write'level] —(0-9) This field applies only to the definition 
of forms. It represents the level of variable Q-field (changeable data) a 
user may insert in a form with program «fgen». Q-fields are assigned 
Write Levels (as well as Read Levels) with program «q». A user may 
only insert variable fields that have Write Levels at or below his own 
Write Level. This is shown in Table A-2.1 under “Write Level.” If a 
user attempts to insert a field that has a higher Write Level than his 
own, yet his Read Level is within the field’s range (logically, the Read 
Levels of users should be higher than their Write Levels), the field will 
automatically be inserted as information-only. Once a user has insert¬ 
ed a variable field to which he has Write Access, he may specify it as 
information-only in the form. 


In order to create, edit or delete forms, a user must have the appropri¬ 
ate program in his List of Available Processes and/or he must have 
Command Interpreter authority. 


Note: Even if the Change Level of a form or list (see User Level) permits 
the user to edit it, the form or list may contain pre-existing fields with 
higher Read or Write (forms only) Levels than those of the current 
user because they were inserted by a user with a higher Read or 
Write Level. In the case of an existing form or list, an appropriate 
Read Level for the current user is sufficient authority to edit or 
delete it. The higher level Q-fields have in effect been licensed to 
the Change Level. 


list level [list'level] —(0-9) The level of list (List name) a user may 
specify with the Directory or Index commands. The user’s List Level 
must be equal to or greater than that of the Access Level of the list. 


User Definition 
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This is shown in Figure A-2.1 under “List Level. It should be noted 
that if a default is made to a List specified in a Basket or Desk Profile, 
the user’s List Level must still permit access to the list. 

Access to lists of users, terminals, desks and baskets, eta, may 
optionally be limited within a system by giving those lists Access 
Levels which are much higher than the List Levels of average users. 

form level [FORM'LEVELl— (0-9) The level of for m a us er may access as 
a take header or with the various levels of IcmdJ 0 (edit, copy or 
create record with form). The user’s Form Level must be equal to or 
greater than the Access Level of the form. Th,s ' s ®hown n F gure 
A-2 1 under “Form Level.” All forms specified in the header field(s) of 
a User Profile must be accessible to the user through his Form Level 
Careful consideration should be given to the Access Levels of take 
header forms (especially advertising headers) and to the Form Levels 
of users required to use them (or of users who are to be denied the 

use of them). 

With regard to forms, other than take headers, that are accessed with 
[cmdI 0 and which represent records in a file, a user must hav 
access not only to the form itself but also to the file it references. 

Command Authorities 

The following are explicit authorities to execute 

and/or to perform various functions with specific commands. An authority 

is granted by typing an «x» in the appropriate field. 

USER modify [a user'define]- A user with this authority may modify 
(edit) the User Profiles of existing users (Icmd] 0) with User Levels 
equal to or less than his own. He may not grant any authority level 
areater than his own respective level, nor explicit access to any des 
or basket to which he does not have implicit or explicit access, nor 
any command authority not specified in his own User Profile. 

user create [a'user'create]— Permits a user to create a new user and 
complete the User Profile under the conditions stated for User Modify 
authority, with the following restriction: Once a User Profile created by 
this user has been filed, he may not edit the User Profile record to 
make additions or changes to it unless he also has User Mod y 

authority. 

user delete fA"usER~DELETE] —Only a user wi th this authority may delete 
a User Profile record from the system with |cmd] □ 0. This authority 
is limited to User Profiles with User Levels at or below his own. 

password [a'password]— Permits the user to change the passwords of 
other users who have User Levels equal to or less than his own. is 
is done with [cmd] □ M- A user with this authority is given a prompt 
for the user name whose password he wishes to change ( n ° rn " ia V 
because the subject user has forgotten his own password). Individual 
users may change their own passwords without this authority. Pass¬ 
word authority should be assigned judiciously (perhaps to only two or 
three high-level users in the entire system), since in the wrong hands 
it can result in serious security violations. 

desk define [a'desk'define] —Permits a user to add, change or delete 
Desk Profiles having Access and Assign Levels at or below his own. 
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Such desks will be available for use by other users with adequate 
Access and Assign Levels, or with the desk(s) named in their lists of 
Explicit Access Desks. A desk may not be deleted if it has any takes 
assigned to it, since that desk is represented in the take headers. Due 
to the normally broad interpretation of desks in the system, it is 
recommended that this authority be restricted to users under the 
direct supervision of the system manager and that requests for the 
addition, deletion or modification of desks be directed to that users. 

basket define [a"bask"define] —permits a user to add, change or delete 
Basket Profiles having Access and Assign Levels at or below his own. 
Such baskets will be available for use by other users with adequate 
Access and Assign Levels, or with the basket(s) named in their lists of 
Explicit Access Baskets. A basket may not be deleted if it has any 
takes assigned to it, since that basket is represented in the take 
headers. Because baskets normally have departmental uses, it is 
recommended that this authority be restricted to the senior editor(s) of 
each desk (department). 

page assign [a>age"assign] —The authority to assign a publication date 
and/or a page name (or number) to a story. A user with this authority 
may assign a publication date without a page, or a page without a 
publication date, or both. 

story release [a'story'release]— The authority to release individual 
stories (with IcmdI m fRl> which have been assigned publication dates 
and page names; a story may not be released without both fields 
being specified. The user must also have a Release basket specified. 

page release [a'page'release] —The authority to release pages (with 
IcmdI □ [r])— by publication date and page name—to which stories 
have been assigned by users with Page Assign authority. The individ¬ 
ual stories assigned to the page need not have been released, but 
both the publication date and page name must have been assigned. 
The page, with an optional message from the user releasing the 
page, is made available to the page dump process run by production 
personnel. 

edit at all [a'edit] —Permits the user to edit a take with IcmdI [e1. Without 
this authority the user may only read takes and IcmdI [e] is treated as 
IcmdI [g1. This authority may be denied a user during early training. 

edit text [a^edit^text] —Permits the user to edit the text of a take, and to 
create or combine stories. Without this authority, a user with Edit 
authority may only change take headers. 

justify [a'justify] —Allows the user to execute the Justify commands. 
Perhaps this authority may be withheld from certain reporters to help 
ease the load on the system during peak periods. Without this author¬ 
ity, users may still execute the justification functions provided with the 
Itrial-setI key. 

proof [a'proof] —The authority to execute the Proof commands— IcmdI [p] 
or IcmdI 00 —which utilize system printers. 


A-2.9 




















User Definition 


Editorial Manager’s Manual 


output [a'film] —The authority to output takes to a typesetting or word 
processing device with IcmdI [o] or IcmdI [7j [oj. Except for word 
processing users, normally this authority should be reserved for pro¬ 
duction personnel who output pages and single takes from Release 
baskets, or execute classified dumps. 

purge [a>urge] —Only users with this authority may purge records from 
files other than the text file. This does not apply to spiking takes or 
deleting users, baskets or desks, all of which are functions that are 
controlled separately. In order to delete a record from a file, a user 
must have purge access to that file as a Tandem user. 

command interp. [a'comint] —The authority to execute the Sll Com¬ 
mand Interpreter with fcKTpf □ and thereby gain access to the entire 
system within the bounds established by Tandem security. The Sll 
Command Interpreter automatically logs the user on as his (last) 
specified Tandem user. This authority should be limited to the system 
manager, to those knowledgeable users reporting directly to him, and 
to the data processing manager and the programming staff, if any. 

wire forward [aT/vireYorward]— Gives a user access to the fields in 
take header forms which specify the forwarding of locally-generated 
takes of regional or national interest to the designated wire service 
computer. Take header forms should be designed so that users with¬ 
out this authority will not see the wire forwarding fields in a take 
header, or so that they will see them as information-only fields. 

mult vdts [a'multiple'vdts] —Grants the user the authority to sign-on to 
more than one vdt at a time. When the user signs-on to a second 
vdt, the system transmits a message reminding him that he is al¬ 
ready signed-on elsewhere; this is a security precaution. 

utility Futility] —The authority to execute utility processes from a list 
(as defined with schedset). Without this authority or cmd interp 
authority, the user may not execute Sll Utility processes. 

story dup. [a"story"dup] —The authority to execute the story duplication 
command ( IcmdI □ [c]). This field is not used if your site uses Sll’s 
optional wisper™ software. 

glossary def [a'gloss'define] —The authority to define glossaries for 
User Defined Keys (udks). 

sdk def [a'sdk'define]— The authority to define System Defined Keys. 

input Ctrl [aTcontrol] —The authority to execute input line control 
commands. 

output ctrl [a“o''control] —The authority to execute output line control 
commands. This field is used only if your site uses Sll’s optional 
wisper™ software. 

remote user [a'remote] —The authority to sign-on to the system from a 
remote terminal. 

bust story [a'bust] —The authority to bust (halt in mid-transmission) a 
story which has been transmitted with the transmit command ( IcmdI 
□ [f]). This field is used only if your site uses Sll’s optional wisper™ 
software. 

send message [a'message] —The authority to send messages ( IcmdI I’m] ). 
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spell [a^spell]—T he authority to execute Spellbinder ( Icmdi □) or Spell- 
binder/sPEDiT ( Icmdi F~h . 


User Defaults 


All User Profile fields are authorities until they are included in the «user 
default» form which is accessed by users with Icmdi [uj. Very simply, if 
you don’t want all users to have access to a field, don’t include it in the 
User Default form. 


Figure A-2.3 illustrates a sample User Default forms for an editorial 
system. The form gives users access to the maximum recommended 
fields. Fields in the form which were not covered in the explanation of the 
user profile are explained briefly below. 

header [header“form] —See “User Profile Field Descriptions” for expla¬ 
nation. 


styl [styl] —See “User Profile Field Descriptions” for explanation. 


output [out'dev] —See “User Profile Field Descriptions” for explanation. 


User Defaults for RICK 

Header SPORT EDITOR STYL SPORT COL Output APS ( DEFAULT ) 

Glossary SPORTS _ Sign-on UDK _ or sign-on SDK _ 

Send Basket _ Desk _ Long Lines _ 

Prefill Story #_ 

Proof _ 

Input text only? _ Output text only? _ Output commands? __ 
Suppress banner? _ Suppress line numbers? _ 

Double spacing? __ Triple? _ 

Baskets _ RICK _ _ SPORTS _ _ SPORT TAB 

_ LOCAL SCORES _ PETE _ R RICH _ 

STRINGERS R SPORT UDK _ 


Desks _ SPORTS _ R GLOSSARY R MEMORANDA 


Directory Formats: 

1. TO SPORT TOPIC 2. KE KEYWORD 3. AU AUTHOR 

4. PG SPORTS PG 5. EX SPORT EXPIRE 


Figure A-2.2. Sample Editorial User Defaults. Required Form Name: «user default». 


( 


tion. 


) [out'loc]— See “User Profile Field Descriptions” for explana- 


glossary [glossary] —See “User Profile Field Descriptions” for explana¬ 
tion. 

sign-on udk [sign'on'udk] —A udk which is to be executed automatically 
each time this user signs on. This feature may be used to execute a 
udk to set up parameters on the Coyote terminal (to select blinking 
cursor or message beep for example). 

sign-on sdk [sign'on'sdk] —An sdk which is to be executed automatical¬ 
ly each time this user signs on. 
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SEND BASKET [send"basket]— See “User Profile Field Descriptions” for 
explanation. 

send desk [send'desk] —See “User Profile Field Descriptions” for expla¬ 
nation. 

LONG LINES [long"lines]— See “User Profile Field Descriptions” for expla¬ 
nation. 

prefill story # [prefill'number] —Use for Advertising Systems. 
proof [proofkey] —See “User Profile Field Descriptions” for explanation. 

input text only? [input"only] —Enter «x» in this field if you wish your 
proofs to display input text only. 

output text only? [output'only] —Enter «x» in this field if you wish 
your proof to display output text only. 

output commands? [show"commands] —Enter «x» in this field if you 
wish commands to be displayed in your proofs. 

suppress banner? [suppress"banner] —Enter «x» in this field to sup¬ 
press the banner at the beginning of each proof. 

suppress line numbers? [suppress'ln] —Enter «x» in this field if you 
wish to suppress line numbers on your proofs. 

double spacing? [DoubleSpace] —Enter «x» in this field if you wish 
your proofs to be double spaced. 

triple? [triple"space] —Enter «x» in this field if you wish your proofs to 
be triple spaced. 

baskets [b"read"only"i / default'bask'i through 

b"read"only / '12 / default"bask a 12] —See “User Profile Field De¬ 
scriptions” for explanation. 

desks [d"read"only"i / default"desk"i through 

d" read-only" 12 / default'desk'i 2 ]—See “User Profile Field De¬ 
scriptions” for explanation. 

directory formats [format"path"i / format" i through 

format"path"5 / formats —Default list names for specific directory 
paths. The first field of each of the five sets is the Path; the second 
field is the List name. These default formats automatically supply the 
List name in directory prompts whenever the associated path is speci¬ 
fied. A List name specified here must exist and the user’s List Level 
must be equal to or greater than the Access Level of the list. Normal¬ 
ly, the paths «ba» and «de» should not be specified here; it is more 
convenient to use the default List styles named in individual Basket 
and Desk profiles. 

Note that in Figure A-2.3 editorial users are given access to, among 
others, the Header field, the default styl name, the Output device fields 
and the default Proof location. To exert greater control over users, you 
may exclude any of these fields. If you want users to be restricted to a 
single udk Glossary, or if you wish to control the destinations to which 
users Send their stories, you may exclude those fields. Only users with 
access to their complete User Profiles (User Modify authority) are able to 
change fields that are not in the User Default form. (It is also possible to 
give certain users User Modify authority, allowing them to use an abbrevi¬ 
ated User Profile form [form «up», for instance, with a lower Form Level]. 
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Such a form should not contain Authority Levels or Command Authorities. 
Access to the entire User Profile form [form «user profiler should be 
restricted with a Form Level of 9.) 


Alternative Default Forms 

In addition to (or in place of) the User Default form, you may wish to 
design small forms (with appropriately low Access Levels) that give users 
access to single fields, or small groups of fields, in their own User Profiles. 
For example: 

Glossary for JOHN _,_ 

John would access this form, named «gloss» for brevity, by executing the 
Edit Form command— Icmdi [f] —and completing the prompt as follows: 

Form GLOSS _ Path _ (Change record) 

Key _ 

John need not enter his name in the key. The signed-on user is assumed. 


Creating, Copying, Editing and Deleting User Profiles 


A user must have User Create authority to create or copy User Profile 
records, User Modify authority to edit User Profiles, and User Delete 
authority to delete User Profiles. Any user may perform any one of these 
functions with only the appropriate authority. Further, the User Profile 
being accessed for any of the above purposes must have a User Level 
which is equal to or less than that of the accessing user. 


Remain aware of the fact that a user may not grant another user access 
to desks or baskets to which he does not have access in his own User 
Profile, nor may he grant any level higher than his own, nor give an 
authority he does not possess himself. 


While creating and modifying users it is most efficient to work from an 
Index of «users» with a list style that displays the record fields in which 
you are most interested—perhaps the user name, full name, Tandem id 
and authority levels. Another list style could display the users’ command 
authorities. Design different lists to display different aspects of User Pro¬ 
files. Working from an index allows you to copy a User Profile that most 
closely matches the definition you wish for a new user. This greatly speeds 
up the task of creating users. 


User Profiles are created, copied and edited with the three levels of 
IcmdI [f] , and are deleted with IcmdI □ [RJ: 


• Create a user record with Icmdi □ [3- Requires User Create authority. 
If the cursor is not on an item in a list of records ( Icmdi [xj, List Name 
«users»), you will be supplied with a blank prompt. If the cursor is 
pointing at a record, the form name (record type) will be filled in for you: 

Form USER PROFILE Path _ (Create record) 

Key _ 


Fill in the name of the new user in the «Key» field and press [return]. A 
blank User Profile form will be displayed with the message “Creating 
record” on the status line. Fill in the profile and execute another com¬ 
mand ( IcmdI m fxl to return to your index), causing the record to be filed. 
If you decide not to file it, you must execute IcmdI ITI. 
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All users, when first created, are automatically null.nulL (000,000) 
Tandem users and will remain as such until they logon as another 
Tandem user defined in the system. Most users will remain null.null 
users, and you need not give their Tandem account number any further 
thought. 


• Copy a user record with [cmdI □ @. Requires User Create authority. If 
the cursor is pointing at an item in a list of records, the indicated User 
Profile record will be copied and displayed with the name field blank. 
The message “Copying record” will be displayed on the status line. If the 
cursor is not on a list item, you will be supplied with a blank prompt. You 
must supply a form name in the «Form» field and a record name in the 
«Key» field to indicate which unique record is to be copied. For example: 

Form USER PROFILE Path _ (Copy record) 

Key ROGER _ 

Press |cmd| and a copy of the User Profile will be displayed, minus the 
new user name which you must supply. Fill in the form and file it. 


• Edit a user record with Icmd] Requires User Modify authority. If the 
cursor is pointing at an item in a list of records, the indicated User Profile 
is displayed immediately. The message “Editing record” is displayed on 
the status line. You may make the desired changes and then refile it. 

If the cursor is not on a list item, you are prompted: 


Form 
Key _ 


Path 


(Change record) 


You must supply the form name— «user profile» —in the «Form» field. 
If you do not type a unique user name in the «Key» field, your own User 
Profile is assumed; otherwise, the User Profile for the user whose name 
you type is displayed for editing. 


• Delete a user record with [cmdI Q [kJ. Requires User Delete authority. 
If the cursor is pointing at an item in a list of records, the indicated User 
Profile is displayed immediately with the following blinking message on 
the status line: “Record will be deleted.” To complete the deletion, 
execute any command which implies filing of the record (e.g., return to 
the Index to note its absence); to abort the deletion, execute IcMDl fTl. If 
the cursor is not pointing at an item in a list, a prompt is displayed: 


Form _ Path _ (Delete record) 

Key____ 

You must type «user profile» in the «Form» field and a user name in 
the «Key» field. The profile will be displayed with a warning message. 


Take Header Form Security 

An axiom applying to the design of take header forms is that a user 
cannot change what he or she cannot see. Additionally, header data may 
be displayed as information-only to some users and as changeable fields 
to other users. 


The simplest illustration of this is found in an editorial application. Fig¬ 
ures A-2.3, A-2.4 and A-2.5 show the way a reporter, an editor and a 
production person would each view the same story. 
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User Definition 


FORM 7-20-83 16:40 

Created by CHARLES on 1/20/81 at 11:16 
Status J, 197 lines, 6933 chars, 27.75 inches 

Story Raiatea _ Topic POLYNESIA Keyword CRUISES _ 

Basket CHARLES Desk TRAVEL _ Author: CHARLES 

Default STYL: TRAVEL Private/Read/Copies _ 

Sally has cuts and unedited captions_ 

By Charles BritcherU 
RAIATEA ALWAYS has been among 
my favorite Polynesian islands, partic¬ 
ularly because although it's less than 


Figure A-2.3. Sample Reporter Header. 


The reporter (Figure A-2.3) has the shortest header form. Only as much 
data is displayed as he needs to do his job. Note that the Author field is 
displayed as information-only. So is the default styl field; he always uses 
the same procedure. Except for the fact that the information is useful, 
these fields could be omitted from the form entirely. Notice that output 
device information is not displayed; he has no need for it. 


FORM 7-23-83 12:54 

changed by: GEORGIA (7/23/83 12:52:27) 

From basket CHARLES on 7/22/83 at 16:47 by CHARLES 
Created by CHARLES on 7/20/83 at 11:16 
Status J, 201 lines, 6996 chars, 30.52 inches 
SPELLBINDER run on 1/23/81 at 12:45:18 with 4 errors 

Story Raiatea _ Topic POLYNESIA Keyword CRUISES _ 

Basket TRAV FEATURE Desk TRAVEL _ Author CHARLES _ 

STYL TRAVEL Output APS (APS.2) Private/Read/Copies _ 
Publication Date 07-25-83 Page Travel 1 

Lead story for Sunday Travel, .jumps to top of page 7_ 

♦ hd, C2, hdc, 140 RAIATEA: £ 

j|cf, al, 36, 30 Fetching on to the South Pacific £ 
c 

By Charles Britcherf 
RAIATEA ALWAYS has been among 


Figure A-2.4. Sample Editor Header. 


The editor (Figure A-2.4) is able to change fields that were informa¬ 
tion-only to the reporter. The output device information is displayed as 
information-only (defaulted from her profile); she isn’t given the authority to 
change it. The major additions to this form are the Publication Date and 
Page fields which she has assigned. Her work with the story isn’t finished, 
however, as Spellbinder has turned up four spelling errors. 


The production header (Figure A-2.5) eliminates the Author and Pri¬ 
vate/Read/Copies fields, which are no longer of interest. Notice that the 
remaining fields have been rearranged, and the statistics (info-only) fields 
have been moved to the bottom. Most prominent is the publication and 
device information which is of greatest interest to production personnel. 
The story name, topic and keyword are on the second line; and the styl, 
basket and desk, which are of incidental interest at this point (except for 
the basket in accessing released stories for this desk) have been moved to 
the third line. The Guide serves to separate the statistics from the text of 
the story. This header gives access to all important fields. 


Notice that Charles’ spelling errors have been corrected. 
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FORM 7-24-83 10:09 

Pub. Date 07-25-83 Page Travel 1 Output APS ( APS.2 ) 

Story Raiatea _ Topic POLYNESIA Keyword CRUISES _ 

STYL TRAVEL Basket TRAVEL _ Desk TRAVEL _ 

Changed by: SAM (7/24/83 9:27:52) 

From basket TRAV FEATURE on 7/23/83 at 14:58 by GEORGIA 
Status J, 201 lines, 6996 chars, 30.52 inches 
SPELLBINDER run on 7/23/83 at 14:15:32 with no errors 
Filmed on 7/24/83 at 9:27:52 Expires 7/25/83 at 14:00:00 
Lead story for Sunday Travel, jumps to top of page 7_ 

♦ hd, c2,hdc, 140 RAIATEA: £ 

j£cf, al, 36, 30 Ketching on to the South Pacific J 
c 

By Charles BritcherK 

RAIATEA ALWAYS has been among 

my favorite Polynesian islands, partic- 

Figure A-2.5. Sample Production Header. 
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SECTION B-1 

Input Routing Record 

The Input Routing Record is the basic control structure for incoming 
material. It contains your parameters for selecting and routing copy to the 
appropriate desks and baskets, default styl procedures for estimating 
each story’s length and eventually typesetting it, and fields for imposing 
system controls on the copy. 

Up to 400 routing records are allowed for each line. Each routing record 
provides for an average of 60 characters of information in compressed 
form (excluding blanks). More or fewer records can be stored depending 
on how much information is put into each record. 

To define or list Input Routing Records, use the name «routing». 

Figure B-1.1 shows a sample Input Routing Record. Following the fig¬ 
ure, each field in the Input Routing Record is discussed in detail. 


Line Name AP HIGH _ Routing Precedence 1290 

Cycle (AM/PM/BC) Service Level ^ Category B_ Priority 

Body/Agate Text/Tab Select . Search Depth 0 

Access ( /C/R) _ Copy ( /C) 

Agate Leading _ Agate Chars _ 

Body Leading _ Body Chars _ 

Expire Hours 0_ Pub Date Hours 0_ 

Effective Times ALL __ 

Header Keyword __ 

Search Word _ 

Destination Basket NATIONAL Destination Desk WIRE _ 

Topic _ Default STYL _ 

Leading Text 

Agate Text ____ 

Proof Key _ 

Message Alert Group _ 

Destinations 

Figure B-1.1. Input Routing Record. 


line name— The logical line name defined in the Input Line Record. If you 
do not specify a line name, the record will be used for all input lines. 

routing precedence —In this five-digit numeric field, enter a number 
defining the priority that the record should receive in your system 
when matched against stories. This precedence is significant in the 
automatic routing process, since the first routing record encountered 
which matches the header attributes of the incoming copy will be the 
record used to process the story. It is important for the records to be 
sequenced from the specific (for example, all stories matching a level, 
category, priority, cycle, body/agate switch, and text/tab switch) to the 
general (for example, everything for a particular wire with a particular 

category) so that the stories will be routed as specifically as possible. 
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For instance, you might wish to assign a routing precedence 
of «10» to flashes and «20» to bulletins, while reserving a block 
of sequence numbers from «50» to «150» for various sorts of 
regular news stories. No two input routing records can have the 
same routing precedence number for the same line. 


Note: When entering data in the following eight attributes fields, do not 
leave any fields blank. If a field is not essential to the routing 
process, enter periods for the full length of the field. 

Also note that the codes and their meaning listed in this section are 
reprinted from publications of the American Newspaper Publishers 
Association Research Institute, principally anpa/ri Bulletin 1312 
(February 1, 1979), updated according to the notes of the Wire 
Service Steering Committee meeting of November 11, 1980, and 
the notes of the Wire Service Codes Committee meeting of June 
10, 1980. These listings are provided for your convenience only and 
Sll cannot be held responsible for changes or errors. Consult the 
publications of the anpa and the wire services for further informa¬ 
tion and to verify codes and their meanings. 


cycle —This two-character field designates the cycle to which copy is 
assigned: «am», «pm», or «bc» (both). 


service level —This one-character field indicates the service level, as 
follows: 


a orb 
c 

dande 

f 

g and/? 

/ 

l-Q 

rands 

t 

u-y 

z 


Nationwide news transmission with ’b’ not necessarily denoting material 
moving on a slow speed ’b’ wire 
Nationwide transmission of standing features 
State and regional wires 

Nationwide transmission of news designated primarily for financial pages 
State and regional wires 

Reserved for future use, possibly for handling supplemental 

State and regional wires 

nationwide sports transmission 

State and regional wires 

Undefined; reserved for future use 

Reserved for wire service 


category —This one-character field designates the category of story as 
follows: 


a 

b 

c 

e 

f 

i 

k 

/ 

n 

9 

r 

s 

t 

u 

v 

w 

xandy 

z 


Domestic, non-Washington, general news items 

Special events, as assigned 

Standing, general features 

Entertainment and culture 

Financial, for financial pages 

International news 


Commentary: Material primarily for editorial and 
Lifestyle 

State and regional (used by ap) 

Individual sports scores (one-line entry) 

Racing results and entries 

Sports, including packages of sports scores 

Travel 

State and regional (used by upi) 

Advisories that affect more than one category 
Washington-datelined general news 
Reserved 

Broadcast copy (upi) 


op-ed pages 
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priority— This one-character field tells the priority of story, as follows: 
f Flash: Highest priority of wire communications (seldom used) 

b Bulletin: Priority level of prime news 

u Urgent: Just under prime news 

r Regular: Routine news copy 

d Deferred: The lowest priority 

a Weekday advance: For use outside of the current cycle of transmission 

s Sunday advance: For Sunday copy 

h Transmissions to be treated with the same priority as’d’ 

y Transmission of certain reruns 

body/agate— Enter «b» here if incoming copy will be body copy; enter 
«a» here if it will be agate copy. 

text/tab— Enter «x» here if copy will be text; enter «b» if it will be tabular. 

SELECT— Enter the standard anpa select code, which is a further break¬ 
down of the category, in this five-character field. Select codes vary 
according to wire service. 

search depth The maximum number of lines to examine for the search 
word. If no entry is made in this field, the entire story will be searched. 

access— The entry in this field determines how users will be able to 
access the stories selected by this record. 

1. If the field is left blank users will have normal access to stories. 

2. You may enter «r» to permit read-only access to stories, or 

3. «c» to permit copies-only access. 

copy— If «c» is entered here, incoming stories matching this record are 
copied and routed to the specified baskets and desks. The search of 
the routing records continues for other matches. A maximum of 60 

matches is allowed for copies-only routing records containing search 
words. 

If this field is blank, this record will be treated as an original routing 
record. Only one original routing record can match a story although all 
routing records available for the line may be checked. This is true 
even if the original routing record specifies search words. 

agate leading— Leading used to estimate length of story. 

agate chars —Agate characters per line. 

body leading— Leading used to estimate length of story. 

BODY CHARS— The number of characters per line for estimating storv 
length. 

expire hours— Override basket expiration. The number of hours the 
story is to remain in the system. 

pub date hours —Publication factor. 

EFFECTIVE TIMES— Times when this record is in effect. If there is a syntax 
error in the effective times field, the record will be in effect all of the 
time. 

In the effective times field, enter the days of the week and times of the 
day when copy governed by this record should be saved in the system. 
The name of each day can be entered in any form, from its full name to the 
shortest unique sequence of characters. Thus, Sunday can be entered as 
«su», Monday as «m», Tuesday as «tu», Wednesday as «w», Thursday 
as «th», Friday as «f», and Saturday as «sa». Specify the hour of day as 
illustrated on the following page. 
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0 - 

midnight- 

1 am 

8 - 

8 

am- 

9 

am 

16 - 

4 

pm- 

5 

pm 

1 - 

1 

am- 

2 

am 

9 - 

9 

am-' 

10 

am 

17 - 

5 

pm- 

6 

pm 

2 - 

2 

am- 

3 

am 

10 - 

10 

am-' 

11 

am 

18 - 

6 

pm- 

7 

pm 

3 - 

3 

am- 

4 

am 

11 - 

11 

am-noon 

19 - 

7 

pm- 

8 

pm 

4 - 

4 

am- 

5 

am 

12 - 

noon- 

1 

pm 

20 - 

8 

pm- 

9 

pm 

5 - 

5 

am- 

6 

am 

13 - 

1 

pm- 

2 

pm 

21 - 

9 

pm-10 

pm 

6 - 

6 

am- 

7 

am 

14 - 

2 

pm- 

3 

pm 

22 - 

10 

pm-11 

pm 

7 - 

7 

am- 

8 

am 

15 - 

3 

pm- 

4 

pm 

23 - 

11 

pm-midnight 


Separate entries in this field with commas, and indicate ranges with 
hyphens. If you specify a day without specifying times, the program as¬ 
sumes that you mean all times on that day. If you leave the field blank, or 
enter the word «all», the program assumes that you want the record to be 
in effect at all times on all days. For example, to specify that incoming copy 
should be saved at all times Saturday through Thursday, and on Friday 
from midnight through noon, you would enter the following: 



Figure B-1.2. effective times Field of Input Routing Record. 

Hours may be specified so that they “wrap around” the day, saving the 
space of entering two ranges for the day, as in Figure B-1.3, which speci¬ 
fies collection times from 10 pm to midnight and midnight to noon on 
Wednesday: 



Figure B-1.3. effective times Field of Input Routing Record. 


To prevent copy of a certain type from ever being saved, create an Input 
Routing record for it, defining it by its attributes, and enter «none» in the 
EFFECTIVE TIMES field. 


header keyword —The word to search for in the incoming wire keyword. 

Two wild card characters may be used in the header keyword (and 
search word, described below): an asterisk (*) and the logical not 
character (- 1 ). 

The asterisk allows you to specify a match on any character and any 
number of characters. For example, if you enter «d *g» in this field, a 
match will be found on all words beginning with «d» and ending with 
«g» (dog, drag, drug, and so on). The asterisk may be used more 
than once in a single search word. An asterisk at the beginning of a 
search word field is considered a character and not a wild card. 


The logical not character allows you to specify a match on any char¬ 
acter, but only on the number of logical not characters specified. For 
example, if you enter «d -, g» a match will be found only on three-letter 
words beginning with «d» and ending with «g» (dog, dig, dug, and so 
on). Multiple logical not characters may be specified. A logical not 
character at the beginning of a search word field is considered a 
character and not a wild card. 
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search word —Word to search for in the story. If found (and there is no 
entry in the topic field of the Input Routing Record), the search 
word is entered in the topic field of the story header. 

The wild card features described for header keyword also apply for 
this field. Search words and searching are independent of case. 

destination basket —The basket to which incoming stories will be sent. 
If no basket is specified here or in the Input Line Characteristics 
Record, the basket defaults to «no match». 

destination desk— The desk to which incoming stories will be sent. 

topic —Topic to be inserted in the story header if no search word is 
specified. 

default styl —Name of default styl to be inserted in the story header. 

leading text —If the search word is found in the story, this text will be 
inserted at the beginning of the story. 

agate text —Text to put out if agate copy (normally a styl call). 

proof key —If this field is completed, incoming stories selected by this 
record will be proofed automatically at the specified location. 

message alert group —The message group to which alert messages 
are to be sent. 

destinations —Destinations for stories to be acted upon by the burster 
process. May include destination baskets for stories and external 
destinations for sites using Sll's optional wisper™ software, wisper 
allows stories to be onward addressed using this field. 
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SECTION B-2 


Input Line Control Commands 


Input lines can be controlled and dynamically reconfigured from the vdt. 
To make changes to the configuration of a line, make the desired modifica¬ 
tions to the Input Line Characteristics Record (see System/55 Input Spool¬ 
ing System Manual [S55-033]) before executing the reconfigure 
command. 

You must also execute [cmd] □ Q] (function «n») when an Input Routing 
Record is changed, added, or deleted. 

To execute a control command on a line enter fcMDl □ (T|. The following 
prompt is displayed: 


Line Name 


Complete the prompt b y entering the name of the line on which you want to 
act and press [return]. The following prompt is displayed: 

Line name LINE NAME is open (released) 

Last line error 66 

Function __ Sequence Number: Current 242 New 

Complete the prompt by entering the letter designating the function you 
wish to perform. 

FUNCTION MNEMONIC DESCRIPTION 


OPEN LINE 


0 


Allows input from the line to enter the 
spooling system. 


CLOSE LINE 


c 


Prevents input from the line from en¬ 
tering the spooling system. 


reconfigure 


n 


Reconfigures a line when changes 
have been made to the Input Line 
Characteristics Record. 


HOLD 


H 


Stops input from a line from being pro¬ 
cessed. Incoming wire is collected but 
is not processed for the text file until 
the release command is executed. 


RELEASE 


R 


Re-starts processing of jobs collected 
from a line put on hold with the hold 
command. 


SET SEQUENCE 
NUMBER 


S 


Sets the sequence number for stories 
coming in on the line. Supply the new 
sequence number in the new field of 
the prompt. 
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SECTION B-3 

Line Statistics and 
Line Status Lists 

Two lists monitor the status of your incoming lines. For each line, the list 
entitled «input status» tells when the last story was received, the se¬ 
quence number assigned the story, the System/55 story number, and the 
som and eom status of the story. (The list is designed primarily for use with 
rgen reports and is sorted fifo when displayed on your vdt.) 

The list entitled «input stats» gives the following information for each 
line: when the line was started, the number of stories it has received, and 
the date and time the last story was received. It is updated each time 
something happens on the line—a story is received or the line is opened or 
closed with a line control command, for example. 

The input lists differ from other input handling records in that you need 
neither create or update these records. Once the input stats and input 
status files are defined and the lists are created using lgen, the incoming 
wires create their own records which are summarized in the input stats 
and input status lists. 

The Input Line Statistics List 

A typical input line statistics list is illustrated in Figure 12.1 below. 
Explanations of pertinent fields in the list follow the illustration. 


Input line 

statistics 



2/02/83 11:25 

Line Name 

Event date & time 

Sea# 

Story# 

Last error IPO 

H FE MB PE 

OR BO Begin status End status 

Characters 

AP HIGH 

1/29/83 18:53:27 

640 

9457 

0 

t * « t t t t * 




3946 

AP HIGH 

1/30/83 23:37:35 

103 

10965 

0 





1351 

AP HIGH 

1/30/83 23:41:50 

441 

3893 

0 





42 


Figure B-3.1. Input Line Statistics. 


line name— The name of the line. 

event date & time —The time the story was received. 

seq# —The transmission sequence number. 

story #—The number assigned in the header of the story. 

last error —The last error on the line. (The Tandem File System Error 
number is given). 

i—An «x» in this field indicates that a story is being created. 

p— An «x» in this field indicates that the story is from the primary intake 
process. 

o—An «x» in this field indicates that the line is currently open. 
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h —An «x» in this field indicates that the line is currently held. 

fe —An «x» in this field indicates that the story had framing errors. 

mb —An «x» in this field indicates that the story is missing buffers. 

pe—A n «x» in this field indicates that the story had parity errors. 

or —An «x» in this field indicates that the story had overrun errors. 

bo —An «x» in this field indicates that the story had buffer overflow errors. 

begin status —The som status for the story. A blank in this column 
indicates a normal beginning of story; an «m» in this column indicates 
an assumed beginning of story. 

end status —The eom status for the story. 

Blank indicates normal end-of-story. 

«i»—the story was truncated. 

«e» —there was a line error. 

«l»— overlength story. 

«w»—overlength word. 

«m»— the eom was missing. 

«t»— character timeout. 

characters— The number of characters received. 


The Input Line Status List 

A typical Input Line Status list is illustrated in Figure B-3.2 below. 
Explanations of pertinent fields in the list follow the illustration. 


Line Name 

Seq# 

Status 

Story# 

updated 

at 

From S-EOM 

Sync Spl 

err Line 

err 





AP HIGH 

320 

OR 

6070 

3/03/83 

10:49:28 

P 


0 

0 





RCA TELEX 

0 

OH 

0 

3/03/83 

10:05:38 



0 

14 





UPI 

235 

OH 

7569 

3/03/83 

10:04:39 

P 


0 

0 






Figure B-3.2 Input Line Status List. 


line name —The name of the line. 

seq#— The transmission sequence number. 

status— The status of the line: 
open (o), 
closed (c), 
held (h), 
released (r). 


story #—The story number of the last story received by the line. 

updated AT— The date and time at which the entry in the list for this line 
was last updated. The entry is updated each time a story is received 
or when a line control command is given for this line. 

from— Indicates primary/backup status. «p» = primary, «b» = backup. 

s-eom The som and eom status for the story. The first character in this 
column is the som status. Possible entries are: blank, indicating 
normal status, and «m» indicating a missing begin-of-story. 
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The second character in this column is the eom status. Possible 
entries are: 

blank —normal end-of story 
«i»—the story was truncated 
«e» —there was a line error 
«l» —overlength story 
«w»—overlength word 
«M»—the eom was missing 
«t» —character timeout 


sync —This field tells whether redundant lines are synchronized. 

«q» in this field indicates that only one of the two lines is collecting 
data (that is, one is quiet). 

«e» in this field indicates that one of the lines is in error. 


«i» in this field indicates that one of the jobs received by the line and 
sent to the spooler was invalid. 

«s» in this field indicates that the lines are not synchronized. 

spl err —Spooling system errors. (The Tandem error number is dis¬ 
played in this field.) 

line err —Line errors. (The Tandem File System error number is dis¬ 
played in this field.) 
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SECTION B-4 

Story Duplication 


The Story Duplication command ( IcmdI □ [cj; see System/55 User 
Commands [S55-024]) allows the user with Story Duplication authority to 
send copies of a story to more than one user or to another basket by 
simply completing one prompt. Thus, it eliminates the chore of copying the 
story the required number of times and transferring the copies to the 
recipients. The recipients may be all at one site (stories may be sent 
between advertising and editorial on mixed systems) or at different nodes 
of an expand™ network. 

When the story duplication command is executed, it activates process 
dup, which finds all the members of the destination group designated in 
the prompt, reads the record for each one, and sends the copies of the 
story accordingly. 


Destination Groups 

Destination Group records determine to which baskets, desks, and/or 
systems copies of a story are to be sent when the story duplication 
command is used. 


There is no practical limit on the number of members in a group. 

To define or list ( Icmd| [x]) destination group records use the name dest 
groups. Two paths are available: path gr lists destination group records 
by Group; path me lists destination group records by Basket. 

A sample destination group record is illustrated in Figure B-4.1. 


Destination 

Group Definition: 


Group Name 

and Filing Group 


Basket/Pre-queue 

(and optional desk) 


OR Svstem Name 



Onward Destinations: 



Tonic Access 

Word-Wrap _ 



Figure B-4.1. Destination Group Definition Record. 


group —The name of the destination group defined by this record. 

filing group —This field is not used for story duplication. 

basket/pre-queue —The basket to which a story addressed to this group 
is to be transmitted. 

(and optional desk) —The desk (if any) to which a story addressed to 
this group is to be transmitted. 

system —This field may be used in conjunction with onward destina¬ 
tions. 
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onward destinations —A 64-character free format field in which you 
may enter destinations for onward addressing. If the destination is a 
basket and the basket name contains embedded spacebands, it must 
be enclosed in opening quotes. 
topic —The topic to be assigned to the story upon transmission. 
access —The access level to be assigned to the story upon transmission 
(Private, Copies only, or flead only). 
word-wrap —This field is not used for story duplication. 

When a story is duplicated, the name of the newly created take will be 
the same as the original unless that take name already exists on the 
rcvr’s system. If the take name already exists, the take number must be 
used to reference the take. 

The basket and desk to which a duplicated story is assigned are deter¬ 
mined by the system on which dup is running. The basket and desk 
defaults to that of the original take if not overridden by the dest group 
record or the request. The request can override the basket and desk of the 
dest group record. 

The story'category field in the header of duplicated takes is set by 

RCVR tO «D». 

If the take is justified, rcvr changes the just'status from «j» to «*» 
and omits the justification data block at the end of the take. 

The originaCuser of the take is changed by dup to the name of the 
user requesting the duplication. 

The name of the system node of dup (for example: \sn) is placed in 
history'type to identify which system sent the take. 

The access field is cleared so that users on the receiving system can 
have full access to the duplicated take. 

Considerations 

Note that the sending system cannot tell whether the basket and desk 
exist on the target system. The receiving process will store the story in the 
specified basket and/or desk even if that basket and/or desk does not 
exist. 

In addition to coordinating the baskets and desks between systems, the 
character sets between the source and object systems must be compatible 
(for example pi font characters in a story being duplicated). 
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SECTION B-5 

Story Transmission 


The Story Transmission function described in this section is available 
only at sites which have SH’s optional wisper™ software. If y our sit e does 
not support this function, use the Story Duplication function ( Icmdi □ [c]) 
described in Section B-4 of this manual. 


Destination and Filing Groups 

Before users can access the story transmission function: 


1. you must define destination groups in Destination Group Records, 
and 


2. include the destinations field in the story header (see “The Desti¬ 
nations Header Field”). 


The burster process (see the WISPER Manual [S55-031]) uses desti¬ 
nation group records to determine to which baskets, pre-queues, and/or 
systems copies of a story are to be sent. When a story is transmitted, 
burster checks the group names specified in the destinations field of 
the story header against the destination group records. 


There is no practical limit on the number of members in a group, and 
groups can be made up of baskets, or lines. 


To define or list ( fcMDl fxl) destination group records use the name dest 
groups. Three paths are available: path fg lists destination group records 
by Filing Group; path gr lists destination group records by Group; path me 
lists destination group records by Basket/Pre-Queue. 


A sample destination group record is illustrated in Figure B-5.1. 


Destination Group Definition: 

Group Name _ and Filing Group _ 

Basket/Pre-queue _ (and optional desk) 

OR System Name _ 

Onward Destinations: ___ 

Topic _ Access _ Word-Wrap _ 

Figure B-5.1. Destination Group Definition Record. 


group —The name of the destination group defined by this record. 

filing group —The name of the filing group (defined in each user’s User 
Profile) which has access to these destinations. The key to this record 
consists of both the group and the filing group. There will be 
multiple records for a given destination group if more than one filing 
group has access to the group. This field is explained in detail under 
“Filing Groups” below. 
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basket/pre-queue —The basket or pre-queue basket to which a story 
addressed to this group is to be transmitted. 

(and optional desk) —The desk to which a story addressed to this group 
is to be transmitted. 

system —If a basket name was not entered in basket/pre-queue you 
must enter in this field the logical name of the system to which stories 
are to be distributed. 

onward destinations —A 64-character free format field in which you 
may enter destinations for onward addressing. If the destination is a 
basket and the basket name contains embedded spacebands, it must 
be enclosed in opening quotes. 

topic —The topic to be assigned to the story upon transmission. 
access —The access level to be assigned to the story upon transmission. 

word-wrap —If the basket entered in the basket/pre-queue field is a 
pre-queue, you may enter the word wrap value in this field. 

Filing Groups 

Filing Groups provide security by preventing users from filing copy to 
any destination they wish. When a filing group is specified in a user’s User 
Profile, the user will only be able to transmit copy to destinations which 
have that filing group specified in the filing group field of the destination 
group record. 

Copy may originate in three different ways: 

1. Users may address stories for transmission; 

2 . copy received on inbound wire lines may be designated for forwarding 
after being stored locally, and 

3. copy may be received from another System/55. 

Each source may specify a filing group, the User Profile for the user, the 
Input Line Characteristics Record for inbound lines, and the system de¬ 
scription file on the receiving system for the remote sending system. 

Each record in the Destination Group file may include the name of a 
filing group which is allowed to address copy to that destination. If more 
than one filing group is to be able to access a destination, multiple destina¬ 
tion group records, each with a different filing group, must be defined. 

Whenever the story header is read to transmit or duplicate the story, the 
filing group associated with the user, line, or system, making the request is 
used to determine which destination group records are applicable. 

The onward destinations field of the destination group record con¬ 
tains addresses which the system will act upon when the record is ac¬ 
cessed. The way in which the entries in this field are interpreted depends 
upon how the story was addressed. 

If a remote system name is specified in the destination group record, 
then the entries in the onward destinations field are assumed to be 
baskets or groups defined on the remote system. 

If a local basket is specified in the basket/pre-queue field, then the 
entries in the onward destinations field are assumed to be destinations 
which are to be put in the destinations field of the story header when the 
transmit command is executed. 
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If a pre-queue is specified in the basket/pre-queue field, the entries in 
the onward destinations field are forwarded to the line and acted upon 
by the receiving system. A sample list of destination group records is 
illustrated in Figure B-5.2. 


Group 

Filing Group 

System 

Basket 

Onward Destinations 

NEW.FEATURES 

SE 

DEMOE 


"NEW FEATURES" 

NEW.FEATURES 

SE 

LATE 


"NEW FEATURES" 

NEW.FEATURES 

SE 

ALE 


"NEW FEATURES" 

SITES 

SE 

LATE 


INFO 

SITES 

SE 

ALE 


INFO 


Figure B-5.2. List of Destination Group Records. 


Using the records listed above, a story addressed to new.features, by 
a user assigned to the se filing group, is sent to the demoe, late, and ale 
systems and deposited into their respective new features baskets. 

A story addressed to sites, by a user assigned to the se filing group, is 
sent to the late and ale systems and deposited in their info baskets. 


If a story is addressed to both destinations, one copy is sent to demoe to 
appear in their new features basket, another is sent to late to be 
deposited in their new features basket; their system will make another 
copy to be deposited in basket info (the same thing occurs on system 
ale). 


If there is more than one entry in the onward destinations field of the 
destination group record, as in Figure B-5.3, copies will be deposited in 
each destination. 


Group 

Filing Group 

System 

Basket 

Onward Destinations 

NEW.FEATURES 

SE 

DEMOE 


MAINTENANCE 

NEW.FEATURES 

SE 

LATE 


"NEW FEATURES" 

NEW.FEATURES 

SE 

ALE 


"NEW FEATURES" 


Figure B-5.3. List of Destination Group Records. 



However, in this example, only one copy will be sent to demoe, and that 
system will have to create the other copy for basket maintenance. 

Note that in both of these examples only users who have filing group se 
designated in their User Profiles may transmit copy to these destinations. 

The filing group cannot be used to provide a default destination group 
because your filing group may have access to more than one destination 
group. The destination group name must be specified in the destinations 
field of the story header. Otherwise, there is no way to know which of the 
destinations referenced by your filing group is intended. 


The filing group can also be used to allow synonym group definitions: to 
allow a particular group name to mean one thing to one group of users and 
something else to another group. Imagine the case of a wire service where 
editors control all filing of copy to line for transmission to subscribers and 
reporters cannot file copy to line. Reporters address stories to their ulti¬ 
mate destinations, however, when they execute the transmit command, 
the story is burst and copies are sent to the appropriate filing editors. 
When the filing editor has reviewed the copy, he transmits it to subscribers. 
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Let’s assume that there are two filing editors, one controlling anews and 
the other controlling bnews. Two baskets are defined, anews and bnews, 
to contain copy for the appropriate editor to review. 


Two lines, and corresponding pre-queue baskets, are set up: line a for 
anews and b for bnews. The destination group definitions illustrated in 
Figure B-5.4, on the following page, could then be set up. 


Group 

Filing Group System 

Basket 

Onward Destinations 

A 

REPORTER 

ANEWS 

A 

A 

EDITOR 

A 

CNEWS 

B 

REPORTER 

BNEWS 

B 

B 

EDITOR 

B 

CNEWS 


Figure B-5.4. List of Destination Group Records. 


Using the destination group records listed in Figure B-5.4, above, when 
a reporter transmits copy to destinations a and b, a copy of the story is 
sent to the anews and bnews baskets respectively for the filing editors to 
review. The copy sent to the anews basket has a entered in the destina¬ 
tions field of the header (obtained from the onward destinations field of 
the group destination record). Similarly, the copy sent to the bnews basket 
has b entered in the destinations field of the header (also obtained from 
the onward destinations field of the group destination record). 


When the anews Editor transmits his copy of the story, it is sent to line 
a; when the bnews Editor transmits his story it is sent to line b (in both 
cases the story is given the selector code of cnews). 


Suppose that we have a third destination group, c, 
illustrated in Figure B-5.5 below. 


with records as 


Group 

Filing Group System 

Basket 

Onward Destinations 

A 

REPORTER 

ANEWS 

A 

A 

EDITOR 

A 

CNEWS 

B 

REPORTER 

BNEWS 

B 

B 

EDITOR 

B 

CNEWS 

C 

REPORTER 

ANEWS 

C 

C 

EDITOR 

C 

CNEWS 


Figure B-5.5. List of Destination Group Records. 


If these records are in effect, reporters can address stories for transmis¬ 
sion to destination groups a, b, and c. Copies will be sent to the anews 
basket with a and c entered in the destinations field of the story header. 
The system combines the onward destinations for group definitions 
which yield the same destination (in this case basket finance). 

Note that onward destinations can also be specified in the destinations 
field of the story header as described under “Specifying Priority and On¬ 
ward Destinations” later in this section. 


The Destinations Header Field 

Before you can transmit stories you must include the field destinations 
in the story header. The field has variable length and may be from 12 to 
192 characters long in increments defined by Sll and the user. At present 
valid sizes for this field are: 24, 30, 32, 40, 50, 60, 64, 128, and 192. 

The destination field in the story header must be completed before the 
story can be transmitted ( ICMDl fT) (T|). 
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Completing the Destinations Field 


Destination names entered in the destinations field are delimited by 
spacebands. A destination may be a destination group, or a basket (note 
that basket names with embedded spacebands must be enclosed in open¬ 
ing quotes). If a basket is specified, the burster process checks to see if 
the basket is a pre-queue. If it is, an auxiliary header is sent to the basket. 
If the basket is not a pre-queue, a copy of the story is made and trans¬ 
ferred to the specified basket. 


Note that several destinations may be specified in the destinations field 
(assuming there is enough space), so that a story may be simultaneously 
transmitted to baskets on the system and to pre-queue baskets or destina¬ 
tion groups for transmission. 

Destination groups allow you to list multiple destinations under a single 
group name. Then, to send a story to all members of the group, you need 
only enter the group name in the destinations field of the story header 
prior to transmitting it. 


Specifying Priority and Onward Destinations 


Priority and onward destinations can also be specified in the destination 
field of the header. This allows you to transmit the same story at a high 
priority to one destination, and at a lower priority to another destination. 


To do so, complete the destination field in this manner: Enter the priority 
at which you wish the story to be sent, followed by a colon. Then, enter the 
destination to which the story is to be sent at that priority in the usual 
fashion (separated by spacebands). If you wish to specify an onward 
address, enter it in parentheses following the destination(s). If a basket 
name has embedded blanks, it must be enclosed in opening quotes. 


The format is illustrated below. Items enclosed in brackets are optional. 

Destinations: [p,1 dest [(onward address)! 

In the example above, «p» is the priority at which the story is to be sent 
(if not specified, the default is used); «dest» is a destination as defined in 
the Destination Group Record, and «onward address» is a destination 
defined on the receiving system to allow onward addressing. 


If onward destinations are specified, more general Group Destination 
Records can be set up as illustrated in Figure B-5.6. 


Group 

Filins Group System 

Basket 

Onward Destinations 


SYS1 

SYS1 




SYS2 

SYS2 





Figure B-6.6. List of Destination Group Records. 


With these definitions, users can address stories to these two systems 
and use the onward address in the destinations field of the story header to 
specify the destinations on the receiving system. 
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For example, the destinations field might be completed as follows: 


Destinations: SYS1 (FINANCE) SYS2 (NATIONAL) 


Figure B-5.7. Completed destinations Field. 

Transmitting a story with these destinations causes a copy to be sent to 
the finance basket on sysi , and to basket national on SYS2. 

With a properly formatted destinations field, it is possible to send the 
same story to multiple destinations at different priorities with a single 
execution of the transmit command. 

Suppose a story is to be sent to three different destinations (sfc, sfd, 
and lax) at two different priorities (u and r), and is to be onward ad¬ 
dressed to two additional destinations when it reaches one of the first 
destinations. The destinations field might be completed as in the exam¬ 
ple in Figure B-5.7 below. 


Destinations: U: SFC SFD R: LAX (UVW.XYZ) __ 

Figure B-7.8. Sending a Story to Multiple Destinations at Different Priorities. 

In the example above the story will be sent to sfa and sfb at priority u, 
and at priority r to lax where it will be given the onward addresses uvw 
and xyz. 


Transmitting Stories 

The transmit story command ( [cm'd! □ 0) “bursts” (creates copies of) 
stories to internal baskets and to pre-queue baskets (for transmission to 
bureaus and/or wire service subscribers for example). 

When the command is executed while a story is displayed, transmission 
of that story is implied. When the command is executed while a story is not 
displayed, the following prompt is displayed: 

Transmit story _ move to _, _ 

When the command is executed, the original of the story is placed in the 
transmit basket specified in the user profile. 

A copy of the take is made for each internal basket and for all the 
outgoing lines. The take is added to the pre-queue at the end of its priority 
grouping and to each designated internal basket according to the basket 
profile. 

Each entry in the pre-queue has an additional header created called an 
auxiliary header. The auxiliary header contains all the information found in 
the standard editorial header; however, only two paths are available to 
access it: basket (ba) and story number/name (sn). All cross reference 
fields (topic, keyword, author) are cleared to minimize data base activi¬ 
ty. 

If you attempt to transmit a story without specifying destinations, the 
message “Story has no destinations specified” is displayed. 

When you attempt to transmit a story from a directory, the destinations 
field is revalidated. If your filing group does not match the filing group of the 
last user who modified the field, an error message is displayed and you 
must edit the story and change the destinations field in order to transmit it. 
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SECTION B-6 

Wire Carbon 


The Wire Carbon feature of System/55 allows newspapers which do not 
purchase Sll’s optional wisper™ software to forward locally-generated 
stories of regional and national interest to a computer at the closest wire 
service office. Wire forwarding is accomplished through this carbon pro¬ 
cess. 

A number of different records and tables contribute to Wire Carbon: The 
story header contains fields for releasing and routing stories to the wire 
service, the User Profile contains a wire forwarding authority field, the 
Wire Carbon record contains the information the system needs to automat¬ 
ically transmit designated locally-originated copy to a wire service the 
name of the wire service, the system-defined name of the transmitting 
modem, the appropriate telephone number, and so on. 

The list «wire carbon» shows the information from the Wire Carbon 
records. The list and the records work on the data file used for the actual 
forwarding. The fields carbon'dest and after'sending are the keys to 
be entered in a directory request using path «ws» to list stories awaiting 
transmission and those already sent. 


The Wire Carbon record is illustrated in Figure B-6.1, and explanations 
of the entries in the fields follow the illustration. 


Wire service _ After sending 

Description ___ 

Dialer name 


Info 


Dialer address _ Modem address _ Modem type 103? _ 

Modem __ 

Wrap Baud rate 


Prefix _ Long distance _ (_) Phone 


Bits _ Parity _ TTS _ CompuServ? _ 


Figure B-6.1. The Wire Carbon Record. 


Fields in the Wire Carbon Record 


wire service —In this two-character field enter the mnemonic for the 
name of the wire service; for example, «ap». This is the same mne¬ 
monic the user enters in the carbon'dest field of the story header to 
designate a story for wire forwarding. The wire sending process refers 
from that entry to this record to find the data necessary for transmit¬ 
ting the story. 


after sending— Enter in this field the two-character code that will replace 
the code from the carbon'dest field in a story after successful 
transmission. For example, «sa» (Sent to Associated Press) to re¬ 
place «ap» after transmitting a story. 

, NF0 — | n this 12-character field, enter information to be appended to the 
story when transmitted; for example, the name of your newspaper. 


description— Use this 40-character field to describe the function of this 
Wire Carbon record. For example, “Wire carbon to Associated Press.” 
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Fields for Multi-line Dialer 

The wire forwarding program, carbon, will support a multi-line automat¬ 
ic calling unit. The following three fields in the Wire Carbon record allow 
the user to indicate that the specified acu is a multi-line dialer and to 
supply unit selection information required by the hardware. 

If no acu is specified in the dialer name field, meaning that an auto-call 
unit is not used, then these fields are ignored. Otherwise, carbon exam¬ 
ines the address fields for any entries. If both address fields are blank, the 
process sends a phone number to a single-line dialer. An entry In either of 
the address fields informs carbon that the acu is a multi-line dialer and 
CARBON sends the indicated addressing information along with the phone 
number. 

These three fields are all string fields which require a «o» entry to 
indicate an address of zero, carbon will not validate these fields but will 
use a default value of «o» for an address or «(blank)» for modem type if 
improper values are found. 

Use of carbon’s multi-line dialing capability assumes that the acu is 
configured with a Racal-Vadic VA831A adapter, which is the hardware that 
requires the dialer and modem addresses. (For more technical information 

refer to the VA831A/B adaptor manual, Racal-Vadic’s publication number 
18008-041.) 

The three fields for multi-line dialers are: 

dialer address— Enter a numeric character to specify a dialer address in 
the range 0-3. 

modem address— Enter numeric character(s) to specify a modem ad¬ 
dress in the range 0-14. 

MODEM TYPE 103?— Leave blank to specify a non-103-type modem or 
enter any other character to specify a 103-type modem. 

MODEM NAME- In this 34-character field, enter the name of the transmit- 
ting modem as it is defined in the system; for example, «$modem». 

wrap (LENGTH)— Enter the maximum line length the destination wire ser¬ 
vice will accept, carbon keeps track of the spaces so that word 
wrapping is possible. If the last word on a line makes the line longer 
than the wrap length, carbon splits the word at wrap\ength. To 
permit forwarded stories to be word wrapped, each wire service must 
have a wrap length in this file. If a wire service doesn’t specify a 
wrap length, stories will be sent line for line without any adiust- 
ments. Any of the following commands in a line will end the wrapping 
of that line: quad right, quad left, or quad center 

BAUD RATE— In this five-digit field, enter the transmission baud rate of this 
modem. 

BiTS-h this one-digit field, enter the number of data bits per character 

rr-' n this one-character field, enter the type of parity employed in 
the transmission. «o» = odd, «e» = even, blank = none. 

tts?- Enter «x» in this one-character field to indicate that the transmis¬ 
sion will use tts code. 
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compuserv?— Enter any non-zero value in this field to indicate that this 
record is for sending stories to CompuServ. carbon, the wire for¬ 
warding process, checks this field in the Wire Carbon record specified 
in each story’s header to determine if the story is destined for Compu- 
Serv. carbon outputs a header format for stories sent to CompuServ 
that differs from anpa standard high-speed wire header by including 
the field retention days, which is the difference between the story’s 
System/55 expiration date and the current date, forced to a value 
between 1 and 999. 


prefix —In this one-digit field, enter the appropriate number (such as «9») 
if it is needed to access an outside line from your site. 

long distance —In this one-digit field, enter «i» if it is required before 
long-distance calls in your area. 

(area code) —In this three-digit field enclosed in parentheses, enter the 
area code of the destination wire service phone number. 

phone —In this seven-digit field, enter the destination wire service phone 
number, omitting the hyphen. 


Story Header Fields for Wire Forwarding 

Several Q-fields in the story header are reserved specifically to accom¬ 
plish wire forwarding for System/55. To get a story forwarded, the newspa¬ 
per must add these fields to those story header forms which will be used 
by personnel having Wire Forward authority in their User Profiles. If a form 
is used which does not display the fields, the values are not lost; they 
simply cannot be changed. 

The wire forwarding Q-fields are described in the following paragraphs. 

carbon'dest —This field is a 2-character carbon destination mnemonic. 
The value in this field is the key to the path «ws». 


carbon'status —This is a 1 -character status field. The following entries 
are allowed: 

* story has been transmitted 
y story must wait before being sent 
blank it is not necessary to wait for filming 

carbon'send —This is a 5-character field in which the user enters a time 
after which the story may be forwarded. 


The vdt control process, econtrol, validates the value entered in the 
wire carbon fields of the story header. Once a non-blank carbon'dest is 
entered, the carbon'status field must contain a «y» or blank. If the 
carbon'send time is left «o:oo», the story will be sent the next time the 
sending process awakes. If a time is entered, it must be in the future. The 
sending process will not send the story until after the specified time. 


The Tandem wire forwarding process ($send) will activate itself periodi¬ 
cally (typically every 15 minutes) and read through the header file using 
path «ws». This search will yield only the stories which have a non-blank 
carbon'dest. If a story that is due to be sent is in use, the sending 
process will skip that story until the next wake-up without any error mes¬ 
sage. An error message will be generated for a carbon'dest value that is 
not found in the Wire Carbon file if the carbon~status value is not an «*» 
(already sent). 
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The sending process generates an “anpa header” at the beginning of 
the story which includes priority and category fields. These default to a 
value of «R» (regular priority) and «a» (general news category). The user 
can override these defaults for a story by entering a value in the 
wire'priority and wire category fields of a story header. The newspa¬ 
per must add these fields to a story header form before users can chanqe 
them. 
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Introduction to DICT 


System/55 uses the complete Webster’s New Collegiate Dictionary 
(©1980 by G. & C. Merriam Co.) both for hyphenation and for checking 
spelling with the Spellbinder™ process. The dictionary is also available to 
all users as a research tool. Only the dictionary Manager may modify it. 

The dict dictionary updating process is a powerful tool for standardizing 
spelling in your publication. With it, you may customize the dictionary, 
which contains more than 110,000 words, to best suit your publication’s 
needs. You may change hyphenation, create, edit, or eliminate words, and 
flag them for inclusion in one of four available subsets. Six subsets are 
available for listing the dictionary. 

Knowledge of the use and operation of dict should be restricted to the 
Dictionary Manager, Spelling Editor, or other person in a position of similar 
authority at your publication, to prevent unauthorized and/or improper use 
with undesirable results. 


The efficient functioning of the justification process and of Spellbinder 
and spedit depend upon a well-managed dictionary. Spellbinder refer¬ 
ences the dictionary to isolate words that do not match dictionary entries or 
have special dictionary flags. A dictionary containing most of the words 
that can reasonably be expected to be found in stories and ads will speed 
Spellbinder processing and make the jobs of the Spelling Editor and Copy 
Editor much easier. 


Summary of DICT Commands 

|cmd| [h] lists the available dict commands. If the cursor is resting on a 
command in the list, Icmdi [h] displays a more detailed description of that 
command. Executing the command again at that point returns to the list of 
commands. 


Table C-1.1 


List of DICT Commands and Their Descriptions 


|cmd| [HI 

Lists commands or gives a detailed description of a com¬ 
mand 

|CMD| [Dj 

Lists words referred to the Dictionary Manager by spedit 
users (automatically executed when dict is started) 

|cmd[ [a] 

Acknowledges a word in the Dictionary Referral list by delet¬ 
ing it (the cursor must point at the word to be acknowledged). 

|CMD| [Yj 

Lists the Dictionary (to interrupt listing press |cmd|) 

|cmd| [c] 

Creates a new word for the dictionary 

[CMDj D 

Edits a word in the dictionary 

|cmd| |k] 

Removes the word from the dictionary 

jCMD] [¥] 

Displays the dict revision level 

|cmd| [7] or 
|cmd| □ 

Exit from dict 
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SECTION C-2 


Listing the Dictionary 


Various listings of the dictionary may be called to the vdt while you are 
running dict. They are called and displayed in much the same way as they 
are during text editing. 


Displaying the Dictionary 


Enter IcmdI [y] to display a prompt for calling a dictionary listing (see 
Figure C-2.1). 


Word 


PROMPT 11/12/81 10:20 

Subset 

!-Object, ?-Questn, @-Slang, 

*-Nohyph, =-Nalpha 

%-Specl 


Figure C-2.1. The Dictionary Prompt. 


There are several ways of c omple ting the dictionary prompt. Generally, 
entering a word and pressing IcKidI will do. The dictionary is then listed 
beginning with the word entered in the prompt. 

Enter the word just as you would type it in text. Do not leave spaces 
between syllables or enter the subset flag in parentheses following the 
word. Otherwise, the resulting listing will not display the intended results. 


Limiting the Dictionary 

Although the dictionary list produced by the method decribed above is 
suitable for many applications, it may display more words than you want to 
see. The inclusion of a trailing asterisk (*) limits the dictionary listing to 
words beginning with the characters preceding the asterisk. 


PROMPT 11/12/81 10:20 

Word adaptor* ___ 

Subset !-Object, ?-Questn, @-Slang, %-Specl 

*-Nohyph, =-Nalpha ___. 

Figure C-2.2. Dictionary Prompt to Display Limited Listing. 


The prompt illustrated in Figure C-2.2 has been completed to match only 
those words beginning with “adaptor”. The resulting display (see Figure 
C-2.3) is in this case a single word. 


Dictionary 

Listing (adaptor*) 

11/12/81 10:22 

Type 

H A word 


Questn 

adap tor 


1 Item(s) 

listed 



Figure C-2.3. Dictionary Listing Resulting from Prompt in Figure C-2.2. 


This feature is also useful if you are unsure of the spelling of a word or 
wish to display all inflected forms of a word. Simply enter the fir st pertinent 
(or known) characters, followed by an asterisk, and press [cmd]. 
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This can be helpful when used with the Create command to enter a new 
form of a word. Call the list as described here, point the cursor to the word 
most closely resembling t he new word, execute ICMDl fcl. make the neces¬ 
sary changes, and press |cmd| . This saves time and eliminates needless 
rekeyboarding of characters. 


Word adapt* 


PROMPT 11/12/81 10:25 


Subset 


!-Object, ? -Questn, @-Slang, 
*-Nohyph, =-Nalpha 


fc-Specl 


Figure C-2.4. Dictionary Prompt to Display Limited Listing. 

The dictionary prompt illustrated in Figure C-2.4 has been completed to 
display all inflected forms of “adapt”. The resulting list is shown in Figure 
C-2.5. 


Dictionary Listing (adapt*) 


Type H A 
* 


Questn 
14 Item(s) 


Word 
adapt 

adapt abil i ty 
adapt able 
ad ap ta tion 
ad ap ta tion al 
ad ap ta tion al 
adapt ed ness 
adapt er 
adap tion 
adap tive 
adap tive ly 
adap tive ness 
ad ap tiv i ty 
adap tor 
listed 


11/12/81 10:22 


ly 


Figure C-2.5. Dictionary Listing Displaying Inflected Forms of “adapt”. 


Displaying a Single Word 

The dictionary listing can be limited to a single specific word by following 
the last character of the word with an exclamation point (I). 


Word cancel! 
Subset 


PROMPT 11/12/81 10:25 


!-Object, ? - Questn, @-Slang, 

*-Nohyph, = -Nalpha 


-Spec! 


Figure C-2.6. Dictionary Prompt to Display a Single Word. 

The listing resulting from the completed prompt illustrated in Figure 
C-2.6 will display only the word “cancel”. 
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Dictionary Subsets 


The dictionary listing can be further limited to a specified subset (objec¬ 
tionable, questionable, slang, special, no hyphenation, or non-alpha char¬ 
acters) by entering the appropriate character (!, ?, @, %, *, or =) in the 
subset field of the of the prompt as illustrated in Figure C-2.7. 


PROMPT 11/12/81 10:27 

Word cancel* _ 

Subset !-Object, ?-Questn, @-Slang, %-Specl 

* -Nohyph, =-Nalpha 

Figure C-2.7. Prompt Completed to Display Questionable Forms of “cancel”. 


Figure C-2.8 illustrates the listing displayed by the completed prompt in 
Figure C-2.7. We recommend that you normally type an asterisk following 
the word when requesting a subset. Otherwise you may have to wait a 
considerable time for the list to be displayed. 


Dictionary Listing (cancel*) 

11/12/81 10:30 

Type H 

A Word 


Questn 

can cel la ble 


Questn 

can cel la tion 


Questn 

can celled 


Questn 

can cel ler 


Questn 

can cel ling 


5 Item(s) 

listed 



Figure C-2.8. Questionable Inflected Forms of “cancel”. 


Specifying a subset is just like directory filtering. Words are displayed as 
they are found and an incrementing counter of “nn Items Rejected” is 
maintained on the status line. You may press Icmdi at any time to suspend 
the search for words to display. IcanceU resumes the search. To cancel 
the search entirely, you must complete another command. 


Search and Replace in the Dictionary List 

You may search in the dictionary list just as you would in a directory in 
normal editing. This can be useful for locating specific word endings—such 
as “ness”—or for finding special characters in words. 


Note: 



Searching is not permitted while the rejection of ineligible items is 
taking place. It is permitted only while a completed list is displayed. 
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SECTION C-3 

Running DICT 


The dict process is used to add, delete, or modify words in the dictio¬ 
nary. When the Spelling Editor runs spedit to make corrections to Spell¬ 
bound stories, he will flag words which he feels should be added to the 
dictionary. Flagging adds the word to the Dictionary Referral List. 

The referral list can be viewed, as shown i n Figu re C-3.1, without 
running dict by executing the Index command ( Icmd| 0) for list “refer” 
(suggested name; no path or key required). This avoids the needless 
running of dict when there are no words to be added to the dictionary. If no 
words have been referred, executing the index command for this list will 
log the message “List is empty” on the status line of the vdt. 


Words referred to Dictionary Manager 

(*,) 11/12/81 

8: 56 

Word 

1st Referrer Date 

Cnt 

Haig 

CHRISTOPHER 11/05 

1 

MX 

CHRISTOPHER 11/05 

1 

cancelled 

3 Item(s) listed 

CHRISTOPHER 11/05 

1 


Figure C-3.1. The Dictionary Referral List as Displayed by the Index Command. 


No action may be taken on the referred words from a list displayed with 
the index command. It is for your information only. 


Starting the Program 

You may execute dict from the Sll Comm and Interpreter. Enter «dict» 
at the semi-colon prompt and press [return]. 

Exiting the Program 

To exit dict, enter IcmdI ITI or lCMP] in. 


The Dictionary Referral List 

When dict is executed, the dictionary referral list is automatically dis¬ 
played as illustrated in Figure C-3.2. At other times while dict is running, 
execute IcmdI 0 to view the list. 


Dictionary Referral List 

11/12/81 

9: 01 

Word 

1st Referrer 

Date 

Cnt 

Haig 

CHRISTOPHER 

11/05 

1 

MX 

CHRISTOPHER 

11/05 

1 

cancelled 

CHRISTOPHER 

11/05 

1 

3 Item(s) listed 





Figure C-3.2. Dictionary Referral List as Displayed in dict. 


The dictionary referral list contains the referred word, the name of the 
first person who referred it from spedit, the date on which it was first 
referred, and the number of times it has been referred. If, for example, a 
single word has been referred seven times, the cnt field will contain «7» 
but spedit will log only the name of the first person who referred it. 
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Removing Words From the Referral List 

Icmdi Ia] removes a word from the dictionary referral list by acknowledg¬ 
ing it. Point the cursor at the word to be removed and execute the com¬ 
mand. The word is immediately removed from the list and the item count 
for the list is updated. No confirmation message is given. 

This is the only way in which words can be removed from the list. 


CAUTION 

Watch carefully for misspelled words in the referral 
list. The person referring the word assumes you to 
be the authority. Look up every word before ad¬ 
ding it. Never assume you know how to spell or 
hyphenate a word, unless it is local slang. 

Watch for generic words in uppercase or with initial 
caps. They may have just happened to have been 
used that way in the story from which they were 
referred. For example, if you enter “South” (word 
was in dictionary as “south”), that word will never 
be accepted as “south.” 


Adding Words to the Dictionary 

Words may be added to the dictionary in the following ways, each of 
which is discussed separately below. 

1. from the referral list, 

2. from a dictionary listing (this is most useful for entering new forms of 
existing words), or 

3. from a blank prompt supplied by the create command. 

When a word has been referred which yo u think is a new form of an 
existing word, enter the Dictionary command ( |cmd| [y]) and fill in the root 
of the word followed by an asterisk (*). You may then view the existing 
forms of the word and decide whether to enter the new word. If you de cide 
to add it, move the cursor to the closest form of the word and enter |cmdJ [cj to 
copy and edit it as described below under “Copying a Word from the Dictio¬ 
nary Listing.” 

Any character in your site’s character set (except for characters which 
delimit words) may be used as part of a dictionary entry. For instance, 
«m*a*s*h» is permitted. Enter the word precisely as it is used at your site. If 
your character set is multilingual, you may enter foreign characters (&, ce, o, 
(3) or accented characters (c, e, 6). There is no need to enter floating accent 
characters, since they should be defined in your character set to be stripped 
for spelling and hyphenation purposes. 

Adding a Word from the Referral List 

To add a word in the Dictionary Referral List, point the cursor at the word 
and execute IcmdI (cj. This displays the create prompt, filled in with the 
word at which the cursor was pointing in the list (see Figure C-3.3). 
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PROMPT 11/12/81 10:02 

Create new word: 

cancelled_____ 

Subsets: ! -Object, ?-Questn, @-Slang, %-Specl 


Figure C-3.3. Create Prompt Displayed from Referral List. 


Copying a Word from the Dictionary Listing 

Call a dictionary listing which will contain a word most closely approxi¬ 
mating the word you wish to add. Point the cursor at that word and execute 
|cmd| (cj. The prompt will be displayed filled in with the word at which the 
cursor was pointing, as illustrated in Figure C-3.4. You must edit the new 
word; duplicates will not be saved. 


Create new 

can celed 

word: 

PROMPT 11/12/81 10:04 

Subsets: ! 

-Object, ?-Questn, 

@-Slang, %-Specl 


can celed 
can cel er 
can cel ing 



Figure C-3.4. Create Prompt Displayed from Dictionary Listing 


Adding a Word from the Create Prompt 

Enter Icmdi [cj while the cursor is not pointing at an item in a dictionary 
list or the referral list. Enter the word in the blank prompt (see Figure 
C-3.5). 


Create new word: 


Subsets: ! -Object, ?-Questn, 


PROMPT 


Slang, %-Specl 


11/12/81 10:03 


Figure C-3.5. Blank Create Prompt. 


Adding Hyphenation Points 

Once the word is displayed in the create prompt, specify the hyphen¬ 
ation points of the word (if any). Do this by inserting a spaceband between 
the syllables of the word (see Figure C-3.6). Required hyphens are repre¬ 
sented by a hyphen ( mother-in-law , for example). 


PROMPT 11/12/81 10:05 

Create new word: 

can celled_ 

Subsets: ! -Object, ?-Questn, @-Slang, %-Specl 


Figure C-3.6. Create Prompt with Hyphenation Points Indicated. 


If you copy the new word from a similar word in a dictionary list, most of 
the hyphenation points will be there already and you will probably only 
have to add the new ending. To prevent a word from being hyphenated, 
enter it with no hyphenation points. 
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Including a Word in a Dictionary Subset 

The create prompt displays four possible dictionary subsets. The sub¬ 
sets instruct Spellbinder to flag the words and add them to the spedit error 
word list, where the Spelling Editor may view and act upon them. Properly 
used, the subsets help to prevent the publication of nonstandard words. 


To include the word in a subset in the dictionary, enter a space after the 
last character of the word, then, in parentheses, the character denoting the 
subset in which the word is to be included, as shown in Figure C-3.7. 


PROMPT 11/12/81 10:08 

Create new word: 

can celled (?)___ 

Subsets: ! -Object, ?-Questn, @-Slang, %-Specl 


Figure C-3.7. Create Prompt with Subset Flag Added. 


Other flags are automatically assigned to words without hyphenation 
points and words with non-alpha characters (discussed separately below). 

Objectionable Words 

(!)—This flags a word as objectionable, for example, an obscenity. 


Questionable Words 

(?)—Use this flag to indicate a questionable or archaic spelling. For 
example, “cancelled” instead of “canceled”. 


Slang 

(@)—Use this flag to indicate that the word is considered slang. 


Words Requiring Special Attention 

(%)—This flag provides a means of identifying words which require 
special attention for some reason. For example, it may be used to flag a 
foreign word which should always be set in italics, or a word which requires 
a trademark acknowledgement, or one requiring accents. 


Completing the Create Prompt 

Press Icmdi to complete the prompt and enter the word in the dictionary. 
The word is immediately available for use. 

If the word has already been entered in the dictionary (this is easy to 
check before reaching this stage by viewing a dictionary listing—see Sec¬ 
tion C-2) the message “Word already exists” is displayed on the status line. 

Press IcancelI to remove the prompt and return to the previous display 
without entering the word. 

Viewed in the dictionary, the new entry would look like this: 


Webster's New Collegiate Dictionary 11/12/81 10:15 

Type H A Word 
Questn can cel la ble 

can cel late 

Questn can cel la tion 

Questn can celled 


Figure C-3.8. Dictionary Listing 
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Words With No Hyphenation Points 


Words which have no hyphenation points are simply entered without 
them, dict flags them in the dictionary listing with an asterisk (*) in the «h» 
field. 


Words With Non-Alpha Characters 

Words which contain non-alpha characters, primarily those with required 
hyphens (mother-in-law, for example) are entered with hyphens in the 
appropriate places and with spaces at optional hyphenation points, dict 
flags these words in the dictionary listing with an equal sign ( = ) in the «a» 
field. 


Capitalization 

If a word is entered as all lowercase (“word”), matches will be accept¬ 
able independent of case. 

If a word is entered with an initial capital (“Word”), matches will be 
accepted with an initial capital or in uppercase. If the word is found in 
lowercase, it will be flagged as “wrong case” («caps»). 

If a word is entered as all uppercase (“word”), it will be acceptable only 
in uppercase. If it is found otherwise, it will be flagged as “wrong case” 
(«CAPS»). 


Plurals 


It is not necessary to enter variations of a word (such as the plural form 
of a root word) since Spellbinder strips prefixes and suffixes if the original 
word cannot be found. 


This is true also of the third person forms of most verbs which add an “s” 
to the infinitive: “to run”... “he runs”, “she runs”. 


Abbreviations 

Abbreviations must be entered without the final period: «lnc», 
«N.A.T.O». This is because the last period is regarded as a word delimiter 
for Spellbinder and for hyphenation. When the abbreviation is found in text, 
the final period (preceding a space or end of line) signals the end of the 
word. The word is looked up in the dictionary minus the final period, like 
the last word in a sentence; if it is in the dictionary with a final period, it will 
not be found. 


Homographs 


Words that are spelled alike, but have different meanings (perhaps 
different derivations) and are pronounced and hyphenated differently, pre¬ 
sent a special challenge. Common examples of such words are: 

in val id (adj.) as opposed to in va lid (noun, adj.) 
pres age (noun) as opposed to pre sage (verb) 


pre sent (verb) as opposed to pres ent (noun) 

The problem here is hyphenation. The justification process cannot dis¬ 
cern context, so you must make the determination of which hyphenation to 
specify based on frequency of use by your newspaper. Do you more often 
discuss “giving invalids presents” or “presenting invalid arguments”? 
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Few homographs requiring different hyphenations exist in English. You 
might flag these as special words with «%» to bring them to the attention 
of the Spelling Editor and the user of Icmd| R. Concerned users can view 
the word in context, and when the meaning you did not enter is used, you 
may put discretionary hyphens in the word to ensure correct hyphenation. 

Most homographs, such as the noun conduct and the verb conduct, are 
hyphenated identically even though they are pronounced differently. 
These words present no difficulty. 

Editing a Dictionary Word 

Icmdi [fj allows you to edit a dictionary word. This command is useful for 
correcting dictionary entries and changing or adding the subset flag. 

When IcmdI \e\ is executed while a dictionary listing is displayed, the 
word on which the cursor is resting is picked up and displayed in the 
prompt for editing. Make any changes as described above and press 
IcmdI . When the edited word is added to the dictionary, the message 
“Re-display list to get correct sort order” is logged on the status line. If the 
spelling of the word was changed, enter Icmdi □ R to redisplay the 
previous dictionary prompt. Press IreturnI without making any changes to 
redisplay the last dictionary list with the edited word in its new position. 


When the command is executed from the dictionary referral list a blank 
prompt is displayed (see Figure C-3.9). It makes no difference where the 
cursor is resting when the command is executed. 


Edit dictionary word 

PROMPT 11/12/81 

10: 17 

Haig 

CHRISTOPHER 

11/05 

1 

MX 

CHRISTOPHER 

11/05 

1 

cancelled 

3 Item(s) listed 

CHRISTOPHER 

11/05 

1 


Figure C-3.9. The Edit Prompt. 


Complete the prompt by entering the word you wish to edit and press 
Icmdi . The word is displayed as illustrated in Figure C-3.10. 


Edit word: 
can celled (?) 

PROMPT 11/12/81 

10: 18 

cancelled 

4 Item(s) listed 

CHRISTOPHER 11/05 

1 


Figure C-3.10. The Edit Prompt. 


Make any necessary changes to the word and press Icmdi . The edited 
word is immediately updated in the dictionary and is available for reference 

by Spellbinder and the justification process on all systems. 

Note: The word remains in the referral list until you remove it with IcmdI |aJ. 
This enables you to enter several forms of the same word. 
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Purging Words From the Dictionary 


IcmdI [k] purges words from the dictionary. It has no effect on words in 
the referral list. (They may be removed only by executing |cmd| [a|.) 


When IcmdI [k] is executed while a dictionary listing is displayed, the 
word at which the cursor is pointing is immediately eliminated from the 
dictionary. The purged word is no longer available for use. 

When a dictionary is not displayed, the following prompt is given: 


Kill dictionary word __ 

Complete the prompt by entering the word you want to purge from the 
dictionary, and press IreturnI . No confirmation message is given. 


Displaying the Program Revision Level 

IcmdI \¥\ displays the dict revision level on the status line. For example: 

Program revision level: S0054.E01.002 (002). 


DICT Error Messages 

The error messages below may be logged on the status line when dict 
is started or while the process is running. Where the message indicates 
some system error or a malfunction beyond your control, no explanation is 
offered. Notify your System Manager when these errors occur. 


User Errors 


“Illegal except on et/960 or equivalent”—Running on incorrect type of 
terminal. 


“Invalid file name for network”—You are attempting to operate dict on the 
network with the wrong file name. 

“Invalid word attributes”—You have entered an unknown word type in the 
Create or Edit prompt or have not formatted the entry properly. For 
example, you may have attempted to include a word in a subset 
without specifying the type in parentheses. 

“Item rejection limit reached”—Too many words were rejected in attempt¬ 
ing to list a dictionary subset. 

“Must point to Referral word to acknowledge” —The cursor must point at a 
word in the referral list to eliminate it with |cmd| [a|. 


“Must run under Sll vdt Control System”—Running on incorrect system. 


“No startup message found”—The system startup message was not re¬ 
ceived. Start dict again. If this message is given again, contact your 
System Manager. 

“open failed for [filename]”— Either the file does not exist, or you do not 
have the authority to access it. 


“Word must not be blank”—You have attempted to complete a prompt 
without specifying a word. 

“Word not found”—The word you are attempting to edit is not in the 
dictionary. 


'Word must not exceed 40 characters”—The maximum length of a word 
which may be entered in the dictionary is 40 characters. 
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“Word already exists”—You have attempted to create a word which is 
already in the dictionary. 


Functional and Programmatic Errors 


“Dictionary not found in config” —System configuration file is incorrect or 
incomplete. Contact your System Manager. 

“Dictionary Referral file not found in config” —System configuration file is 
incorrect or incomplete. Contact your System Manager. 

“Fatal i/o error in [filename]”—There has been a hardware failure, the disk 
drive is not functioning properly, or the file is full. Notify your System 
Manager. 

“Unable to delete previous version of word”—The process could not de¬ 
lete the original version of an edited word. Contact your System 
Manager. 

“Unable to update the word”—A file management error prevents updating 
an edited word. Contact your System Manager. 
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SECTION D-1 

MAINT Process 

MAINT is a utility process used to maintain baskets and desks. 

It is intended to be run any time the sorting order or sorting field of a 
basket or desk changes, maint is also used to fix basket or desk definition 
files after a change is made to a Q-field name. 

When maint processes stories, it recalculates offsets and sequencing 
information and writes new headers for all stories affected. When it is run 
after a Q-field change, maint simply updates offsets and sequencing infor¬ 
mation. 

MAINT User Identification 

The maint process logs on as user «maint», so program b (busy) will 
know who is updating data. If a story to be updated is locked, maint skips 
the story and sends a message informing the operator what is being done. 

Basket and Desk Sorting 

Basket and desk profiles contain the following line: 

Sorted (L,F,A, or R) _ by (field name) _ 

This is where the user specifies the order in which the contents of the 
basket or desk will be sorted. The four options are as follows: 

l— last in, first out (lifo) 
f —first in, first out (fifo) 
a —alphabetically by the specified field name 
r —in reverse alphabetical order by the specified field name 

If a basket or desk is to be sorted in alphabetical or reverse alphabetical 
order, the name of a Q-field by which to sort must be entered. Typical 
entries are story'name or topic. Refer to the sections on the header 
structure in the Index of Record Structures (S55-007) for listings of all 
available fields. 

The contents of baskets and desks are sorted as initially specified in the 
basket and desk profiles until the sort method is changed. All stories 
entered after the change will be sorted according to the new method, but 
the stories filed before the change will still be sorted according to the 
original method unless maint is run against the altered basket. 

If the user wants to have all the stories in the desk or basket sorted by 
the new method, maint should be run against the basket or desk to 
reorder all the stories. 


Running MAINT 

The maint process is run from Sll Command Interpreter: 

;maint 
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Exiting MAINT 

To exit maint enter «exit» at the question mark prompt or press IcTRU fYl. 


MAINT Help 

The help command provides a short listing of all the maint commands. 
Execute maint as described above and enter «help» after the «?» prompt, 
as shown in Figure D-1.1. 


?help 


BASKET file name 

reorder basket 

HELP [command] 

print long command description 

EXIT (or EOF!) 

terminate execution of program 

DESK file name 

reorder desk 

FIX basket or desk 

recalc offset in desk or basket file 

BLIND 

delete bad blind box and reply records 

TEAR 

delete bad tear sheet records 

CLASS name or number 

reorder classifieds 

LOWERBOUND 

set blind box lower boundary 

UPPERBOUND 

set blind box upper boundary 

DUMP 

delete out of date dump item records 

STATS 

delete excess class stats records 

TRACKING 

maintain ad tracking file records 

EXTRACTS [fileset] 

build header extract records 


Figure D-1.1. Short help Directory for maint. 


Reordering Baskets and Desks 


If a Q-field is changed in a basket or desk, or the order of story sorting is 
altered, maint will reorder it by rewriting the headers of stories in the 
basket or desk. Enter 


?BASKET (basket name) 
or 

?DESK (desk name) 


When you enter the basket or desk command, there is a slight pause 
while maint reorders the file. When the process has finished, maint 
informs you of the number of stories affected by the resorting: 

?n stories resorted 


Fixing Baskets and Desks 

If a structure is changed, thereby changing byte offsets and byte counts, 
maint will fix the baskets or desks by rewriting record definitions. Enter: 

?FIX BASKET 
or 

?FIX DESK 


Building Header Extracts 

The command extract (fileset) constructs and writes records to header 
extract files. 


Advertising Commands 


The remaining maint commands— class, lowerbound, upperbound, 
dump, stats, and tracking —apply to advertising systems only. 
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MAINT Error Messages 

The following messages may be given while you are using maint. Most 
messages occur immediately following the command entry which generat¬ 
ed the error. 

“Abbreviation not unique”—The command abbreviation is not understood. 
Add a sufficient number of letters to make the command recognizable 


to the system. 

“case statement index out of range”—There is a problem with the maint 
process. Contact your Sll System Engineer. 

“Command parameter missing”—A required string modifier is miss ing. 

Request detailed help for the command. 

“Couldn’t change to network form”—System was unable to access network 
mode. 


“Fatal i/o error in [file name]”—There has been an irrecoverable error. 


“Header update failed”—Failed to accept header resequencing command. 
Try again. The header may have been busy. 


“Invalid command”—The command is not recognized. Enter Help for a list 
of acceptable commands. 

“Key position or position failed for [file name]”—Probable hardware failure. 

“Missing system identifier”—The correct system not correctly specified. 
Ensure you are in the same system you are attempting to run maint 
against, or that the correct system is specified in the configuration file. 



« 


More than 10,000 active ads, class not sorted”—Input has exceeded a 
programmed limit. If this is a problem, contact your Sll System Engi¬ 


neer. 


“No config file entry found: blind box”— There is no Configuration file 
entry for the Blind Box file or it is improperly defined. See your System 
Manager. 

“No config file entry found: tear sheet”— There is no Configuration file 
entry for the Tear Sheet file or it is improperly defined. 

“No configuration file”—The Configuration file cannot be found. 

“No param expected, was ignored”—Improper or superfluous parameter 
entered. Enter «help» for correct placement of parameters. 

“No startup message found”—The system startup message was not re¬ 
ceived. Start maint again. 

“open failed for [file name]”— Either the file does not exist, or you do not 
have the authority to access it. 

“Sign on failed, maint in use”—Another user is running maint on the same 
basket. Two users may not run maint on the same basket simulta¬ 
neously. Discuss the difficulty with the other user; you may be work¬ 
ing at cross purposes. 

“Story [name and reason] was skipped”—The story was skipped when 
resequencing was attempted. Try again after a short wait. 
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APPENDIX A 


Listing the Dictionary 
with RGEN 


Numerous reports may be written with the report generation process 
«rgen» to list the dictionary and its various subsets. Please consult the 
Report Generation manual (S55-013) for details on using rgen. 

The name of the dictionary file in all systems is «(volume).dict.mas- 
ter» and the structure used is «dict , 'master». Refer to the Index of 
Record Structures (S55-007) for information on listing Q-fields. 

Figure A-1 illustrates an rgen data take to list all questionable words in 
the dictionary and Figure A-2 shows the report produced. Questionable 
words are selected with the «select questn» statement. Other fields 
representing subset flags are: «objectn», onon'alphA”, «slang» and 
«special» (consult a list of Q-fields). The field containing the dictionary 
word is «LETTERS». 


The list may be narrowed to a particular range by using the startkey 
and stopkey modifiers to the detailfile command; the dictionary word, of 
course, is the key. In Figure A-3, the startkey is «c» and the stopkey is 
«c"» to list all of the questionable words (same select statement) for the 
letter c. Note that the tilde («"») is the highest character in ascii sort 
sequence. Figure A-4 shows the report produced with this data. 


Please use good judgment in running dictionary reports. Some can be 
quite time consuming and will delay the processing of other reports. Run 
them during periods of low system activity. (You may schedule them for 
the middle of the night if you like.) 


It is not recommended that the entire dictionary be listed. This is gener¬ 
ally unnecessary and a great waste of printer paper and time. List only the 
particular ranges and subsets in which you are specifically interested. 
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Story ? words _ Topic _ Keyword -- 

Basket REPORTS _ Desk _ Author WEBSTE R_ 

STYL _ Output DATA ( TANDEM ) Template _ Private? _ 

Lists all questionable words in dictionary-- 

! This report lists all questionable words 

! in the dictionary. 

rgen /out $s. NAME, rgen/ e, (volume), (sub volume), (conf ig file name) 

DETAILFILE (volume), diet. master STRUCTURE dictYnaster 
SELECT questn 

TITLE "Questionable Words in the Dictionary" 

LIST by letters skip 0 head 


Figure A-1. rgen Data Take to List All Questionable Words in the Dictionary. 


Page 1 12/15/81 13:36:09 

Questionable Words in the Dictionary 

adaptor 

adaptors 

cancellable 

cancellation 

cancelled 

canceller 

cancelling 

catalogue 

cataloguer 

catalogues 

centilitre 

centilitres 

centimetre 

centimetres 

centre 

centres 

channelled 

channelling 

criterions 

imbedded 

litre 

metre 

etc.... 


Figure A-2. Report Produced by rgen Data Take in Figure A-1. 
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Story ? words _ Topic _ Keyword - 

Basket REPORTS _ Desk _ Author WEBSTE R- 

STYL Output DATA ( TANDEM ) Template _ Private? _ 

Lists all questionable words beginning with "c" -- 

! This report lists all questionable words 

! for the letter "c". 

rgen /out $s. name, rgen/ e, (volume), (sub volume), (config file name) 

DETAILFILE (volume), diet. master STRUCTURE diet master 
STARTKEY "c" STOPKEY "c~" 

SELECT questn 

TITLE "Questionable Words in the Dictionary" 

TITLE "Beginning With Letter 'C'" 

LIST by letters skip 0 head 


Figure A-3. rgen Data Take to List Questionable Words for the Letter C. 


Page 1 12/15/81 13:36:09 

Questionable Words in the Dictionary 
Beginning With Letter 'C' 

cancellable 

cancellation 

cancelled 

canceller 

cancelling 

catalogue 

cataloguer 

catalogues 

centilitre 

centilitres 

centimetre 

centimetres 

centre 

centres 

channelled 

channelling 

criterions 

17 record(s) processed 


Figure A-4. Report Produced by rgen Data Take in Figure A-3. 
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APPENDIX B 

DSTOCKS 

AP Digital Stocks Process 


Note: This section presumes a thorough knowledge of Associated Press 
Digital Stocks transmission formats. 

The high-speed non-interactive dstocks process receives Associated 
Press Digital Stocks stories via a Universal Multiplexer and processes 
them for typesetting on System/55. 

The Digital Stock Wire is a service which transmits complete stock 
tables daily at high speed (9600 baud) and in a special format. Each stock 
table—referred to as an item —is transmitted in a format which enables 
automatic computer processing of the data at the newspaper. 

Refer to the Associated Press Digital Stocks documentation for details 
of item codes, transmission formats, data location within formats, and so 
on. 


The Configuration File 


Instructions placed in configuration file records control the way dstocks 
processes each item. Figure B-1 shows a sample configuration file record 
for a dstocks process. Following the illustration are explanations of the 
pertinent fields in the form. 


System E Rec _ Process type 2_ Record #169 

Process Name $ESTX _ 

Program file name $SYSTEM.SII.DSTOCKS _ 

Primary CPU 2_ Alternate CPU 0_ Available CPUs -1 

Priority 147 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class STOX Reference name _ 

Home Terminal __ Rund _ 

Input file name ________ 

Output file name ___ 

Parameter string SYSTEM, COMM MUX FILE, [USER NAME] , _ 

fERRORS1, [SAVE ERRORS], fDEVICE NAME1, [FONT NAME], [DEBUG 

name! 

Figure B-1. A Sample Configuration File Record for a dstocks Process. 


system is the system in which dstocks is to run («e» for Editorial). 
dstocks must be run in editorial systems. 

comm mux file is the file into which data is received. 


user name is an optional user name the newspaper may specify for 
dstocks to use. If not specified, dstocks signs on to digital stox. 


errors This parameter is currently not in use. 
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SAVE ERRORS is a switch that specifies whether bad blocks should be 
saved or deleted: 

y means that everything should be saved. 
n means that a take should be aborted on errors. 

The default value is n. 

device name is the name of the device containing the font pointing to the 
recode table that allows conversion of the ap ascii character set to the 
local character set. Generally, this is a device name established to 
contain the font names that access recode and other tables not 
actually connected with the phototypesetter. The default value is 
«convrt». (See also the Device and Font Management manual 
S55-002.) 

FONT NAME is the font that points to the recode table (see device name 
above). The system default value is «dstocks». If the font is not 
found or not specified, the default font for the device will be used. 

debug name is the name of a file to which data received from the Univer¬ 
sal Multiplexer is to be written. If specified, data is written but not 
processed. 

Character Recoding 

The ap ascii characters are recoded via the recode table specified. 

Each character in the table is presumed to represent the same xyzz 
value as the corresponding ap ascii character. This xyzz value is looked 
up in the local character information file. The local character whose xyzz 
value matches that of the ap ascii character is then inserted into the table. 
Characters for which no match can be found are not recoded. 

A «-i» entered in the recode table as the Character Sequence Number 
indicates the lightface character position. A «- 2 » indicates the boldface 
character position. A «-3» indicates the escape character position. 

DSTOCKS Processing 

Each Digital Stocks story received is processed according to a process¬ 
ing table specified in the configuration file. There are two types: 

Record type 72, the Digital Header Table, and 
Record type 73, the Digital Processing Table. 

Each Digital Stocks take can be thought of as follows: 

[header record] 

[line 1] 

[line 2] 

[line 3] 


[line n] 

The Digital Header Table is used when Digital Stocks headers are 
received. Each header points to a Digital Processing Table to use for 
subsequent lines in the story. Each header record is processed by a 
header processing record, and each line is processed by an item process¬ 
ing record. All lines in a story are processed by the same item processing 


The Header Processing Record 
illustrated and explained below. 


and the Item Processing Record are 
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Note: 



In any literal field in the Header Processing and Item Processing 
records, a circumflex (“) may be used to specify trailing blanks. If it 
is the last character in the literal, the circumflex will not be included, 
but all blanks before it will be. 


The Header Processing Record 


The list “Digital head» shows all the Digital Stocks header processing 
records in the system. Figure B-2 illustrates a sample header processing 
record. An explanation of the sample record follows the illustration, and 
detailed descriptions of the fields in the form follow the general explana¬ 
tion. 




Figure B-2. Digital Stocks Header Processing Record. 


The Header Processing Record illustrated in Figure B-2 specifies the 
following processing. 


As its name indicates, it controls processing of transmitted header rec¬ 
ords for item ais, the “a” Consolidated Stocks 500 Selected Final, trans¬ 
mitted at approximately 5:45 pm, Eastern Standard Time. The collection 
times test specifies that items of this type coming in at any time, will be 
collected and processed. The processing name and concatenation fields 
specify that the Item Processing Record whose name matches the format 
number in the transmitted header record will be used to process the lines 
of data in the story. At the end of each line, user event 3 will be inserted; its 
meaning is defined in the styl specified in this record, and will usually be a 
quad left command. 


In the header of the System/55 story created to contain each incoming 
Digital Stocks wire story processed by this record, “Digital stox» will be 
placed in the Basket field, the item number «A18» will be placed in the 
Keyword field (thus enabling the user to get a list of all stories cre ated 
this header processing record), «stocks» will go into the styl field, an 
«aps» will go into the Device field. 
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The insertion text lines specify that the first line of the story will contain 
the styl call character (♦), followed by the format number from the 
transmitted header record (which matches an entry point in the stocks 
styl procedure), followed by a comma, the month from the transmitted 
header record, a comma, the day from the header record, a comma, the 
year «83» as specified in this Header Processing Record, and a blank 
space (which indicates the end of the styl call and triggers an end-of-line 
event in the styl). 

The last line of this record specifies a styl entry to be used for handling 
fractions in the transmitted copy that are not standard ascii characters. 

Header Processing Record Field Descriptions 

header processing name is the name of the header processing entry. 
When a header is received, the four-character name is looked up in 
this file. While header names are always four characters, the final 
character is used only to indicate the approximate time of day this 
item represents. For example, item number «ai i » carries New York 
Stock Exchange sales, with report times indicated as follows: 


A111 

ii 

All 3 

noon 

All 4 

1 pm 

All 5 

2 pm 

All 6 

3 pm 

All 9 

final 


If a header is not found, the final character of the name is set to [ascii 
blank], and the truncated name is looked up. If this fails, a header 
processing name of «*» is looked up to access a Header Processing 
Record that will extract from the transmitted header the data needed 
to specify processing for any item. If this fails, the item is rejected. 

The field is five characters long. This allows ordering within a given 
subset. All referencing is done by generic key position, of count 4, 3, 
or 1. 

days of the week —Enter an «x» following the name of each day on 
which incoming digital stocks header records are to be saved and 
processed. 

time of day —Enter the hours during each specified day when incoming 
digital stocks header records are to be saved and processed. The 
record expresses the collection times in the form “Now is greater than 
or equal to the beginning hour and less than or equal to the ending 
hour.” To specify the entire 24-hour day, enter «0:00» as the begin¬ 
ning hour and «24:00» as the ending hour, as shown in Figure B-2. 

processing name is the name of the line processing record to be used for 
processing each subsequent line. This name is also looked up generi- 
cally to provide ordering. The user may not wish to specify the exact 
name here, but instead to use the next two fields to specify certain 
information to be extracted from the transmitted header record and 
concatenated with the processing name to complete that name. 

Typically, as in Figure B-2, this will be the format number, which is 
also given to the Item Processing Record. Each header specifies the 
format of each subsequent line, and this field may be used to choose 
a line processing record. 
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pos specifies the byte offset position of the desired data in the header 
record (36 for the format number). 

for is the count of characters to move from the data at the specified 
position into the Processing Name. 


trailing text is text to put at the end of each line of the header record. As 
in Figure B-2, it is usually a user event defined in the styl as a 
line-ending command. 

max errors is the maximum number of lines with errors dstocks will 
accept before aborting the take. 

header information is information to put into the System/55 header of 
the incoming Digital Stocks story: the basket and desk to which it will 
be routed, the topic and keyword, the styl and output device. 

insertion text is text to be inserted on the first line of the story. Each of 
the four insertion text entries allows a literal and a move from a 
position in the header record itself. A typical use of the insertion 
text entries, to call a styl entry point and get the date, is shown in 
Figure B-2. 

fraction is a literal to insert (usually the name of a fraction-building styl 
to use) when an escaped fraction with a base other than 100 is 
encountered. An escaped fraction is one for which there is no stan¬ 
dard ascii character, such as 15 / 16 . Escaped fractions with a base of 
100 can be expressed as decimals, and are treated differently, as 
discussed below. 


If present, the literal will be inserted, followed by a comma, the 
numerator, a comma, the denominator, and a blank. If the fraction has 
a denominator of 100, only the character entered in the denominator 
field (usually a period or decimal point), followed by the numerator, 
will be inserted. 


If the literal is not present, dstocks will use the literals entered in the 
next two fields to put out the non-decimal fractions directly: the nu¬ 
merator literal (if present), the numerator, the denominator literal, 
and the denominator. (If the denominator literal is absent, a hyphen 
«-» will be put out.) 


Here is an example of how the fraction fields work: 


1. The transmission sequence for escaped fractions is as follows: 
(ESC (OCTAL 233))(N1)(N2)(N3). 

(ni ) describes the fraction’s denominator: 


4 = 16ths 



5 = 32nds 

6 = 64ths 

7 = 128ths 

8 = 256ths 

9 = 512ths 

a = 10Oths (cents) 

E = Unreduceable 32nds for government and agency bonds 

<N2> is the first digit of the numerator, or a thin space, or a null. 

(N3) is the second digit of the numerator or first digit if only one. 

If the value of the stock is 15 / 16 , in the table above the denominator 
value for 16 is «4». The numerator is determined as explained in 
steps 2 and 3 below. «415» will be transmitted. 
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3. If a literal has been entered in the fraction field, for example, 
«4frac» as shown in Figure B-2, the received data will be pro¬ 
cessed to read «^frac, 15,16». The STYL will recognize «15» 
as the numerator and «16» as the denominator and will set them in 
the appropriate size (superior and inferior, in this case) and font, 
inserting a fraction bar between them. When output, they will look 
like this: « 15 / 16 ». 

4. If no literal is entered in the fraction field, the numerator and the 
denominator will be output directly, separated by whatever literal is 
entered in the denominator field (in Figure B-2, a decimal point): 
«15.16». 

5. If, in addition to no literal in the fraction field, there is no literal in 
the denominator field, the numerator and denominator will be 
output directly, separated by a hyphen: «15-16». 

6. If the value of the stock is 15c, it will be transmitted as «A15». 

7. If a literal has been entered in the fraction field, for example, 
«^frac» as shown in Figure B-2, the received data will be pro¬ 
cessed to read “♦frac, 15, ioo». The styl will recognize «15» 
as the numerator and «100» as the denominator. Additionally 
recognizing «15/100» as a decimal fraction, it will precede the 
numerator with whatever literal is entered in the denominator 
field (in Figure B-2, a decimal point) and delete the now-superflu¬ 
ous denominator. When output, the fraction will look like this: 
«. 15 ». 

The Item Processing Record 

The list digital proc lists all the item processing records in the system. 
Figure B-3 illustrates a sample Item Processing Record. Detailed de¬ 
scriptions of the fields in the form follow the illustration. 

The sample Item Processing Record shown in Figure B-3 defines pro¬ 
cessing for lines in Digital Stocks takes having format 001 in their transmit¬ 
ted headers, as specified in the Header Processing Record for the item. 
Since the masking test fields are blank, no tests will be performed. Howev¬ 
er, the use next record also flag is set, so dstocks will process each 
line as specified in this record, then continue with the specifications in the 
next record. 

The first of the test/move directive groups tests to see if the take being 
processed marks an alphabet break in the item—that is, the end of the 
stock listings beginning with one letter of the alphabet and the beginning of 
the stock listings beginning with the next letter of the alphabet. If the test is 
true, dstocks will insert user event 3 and move one character of data 
found at byte offset 8 into the take, then, as specified by the «!» in the 
continuation code field, stop processing the take. 

If the test is not true, dstocks will process each line of the take as 
specified in the remaining test/move directive groups. It will move the 
specified number of characters from the specified byte offset locations, 
stripping leading fixed spaces and converting numbers and fractions as 
required according to the type codes entered, and inserting user events as 
specified to perform their functions defined in the styl. In this case, these 
test/move directive groups are putting the yearly high and low prices, the 
stock names, dividend values, and so on, into the take, with the appropri¬ 
ate tabbing and line ending commands according to the STYL-defined user 
events. 
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Item processing name format 

, 001 





If pos 

value 

type 

and/or 




pos 

value 

type 

and/or 




pos 

value 

type 





then use this record: 

(Use 

i next record also x) 


If pos 

= value A 

type 





then 0 

pos 8 

for 1_ 

type _ 

and 


j 

If pos 

value 

type 




then 

pos 16 

for 22 

type 1 

and 

m 


If pos 

value 

type 




then 

pos 39 

for _ 

type 1 

. and 

i m 


If pos _ 

value 

type 




then 

pos 45 

for 2_ 

type 1 

and 

m 


If pos _ 

value 

type 




then 

pos 53 

for 4_ 

type _ 

and 

s 


If pos _ 

value 

type 




then 

pos 57 

for 7 _ 

type 1 

and 

m 


If pos _ 

value 

type 




then 

pos 64 

for 2_ 

type 1 

and 

m 


If pos _ 

value 

type 




then 

pos 66 

for 8_ 

type 3 

and 

m 


If pos _ 

value 

type 




then 

pos 74 

for 2_ 

type 1 

and 

m 


If pos _ 

value 

type 




then 

pos 76 

for 8_ 

type 3 

and 

m 









Figure B-3. Digital Stocks Item Processing Record. 


The Fields in the Item Processing Record 


item processing name is the name of the item processing record, which 
corresponds to a processing name specified in a header record. 

Mask Bit Tests 

Selection criteria can be used to test mask bits in certain item process¬ 
ing formats. Figure B-4 shows a typical mask bit test in an Item Processing 
Record. This testing procedure allows the user to select only the tested-for 
sub-group within the data for processing. For example, the over-the-count¬ 
er item provides data on more than three thousand stocks, but three mask 
bits are available to test, each providing a different selection of the total 
stocks. Thus, the second mask bit allows the user to select a regional 
listing (New York, Florida, New England, Northern California, or Southern 
California), while the third mask bit allows a choice between bank and 
insurance stocks. 
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Item processing name format 

002 

If pos 2 & value 4 

type % and/or _ 

pos value 

type _ and/or _ 

pos value 

type _ 

then use this record: 

(Use next record also _) 


Figure B-4. A Typical Mask Bit Test in a Digital Stocks Item Processing Record. 


The Processing Record shown in Figure B-4 is for format 002, Daily 
Over-the-counter, Mutual Funds, and Untraded Bid-Ask stocks. The Mask 
Bit Test portion illustrated performs a logical and test («&») on position 2 
(“Select list mask -2”) for a literal value of 4 (expressed in octal notation, as 
specified by «%» in the type field). For list mask -2, the octal value of 4 is 
the Northern California list. Thus, this record tests each line in the item to 
see if it has that value in the specified position, processing it according to 
the specifications in the rest of the table if it does have that value, and 
discarding it if it does not. The take created in the system will contain only 
the stocks in the Northern California list. 

There are five fields in the mask bit tests: 

pos is the byte offset position of the mask bit to test, and the next, 
unlabeled, field is the test function. The test functions include 

= equals 

# not equals 

< less than 

> greater than 

& logical and (this is the usual test function for masks) 

! logical or 

% exclusive or 

value is the literal value to test against. 

type is the type of the literal—that is, the way in which the value is 
expressed—and includes the following symbols: 

[blank] ascii string 

# Decimal number 

% Octal number 

/ Hexadecimal number 

and/or is a continuation indicator. Depending on the outcome of the 
previous test, a decision must be made to continue or to stop. The 
two possible values are: 

& and 


If the test succeeds, and and/or is or (!), the record is selected. If the 
test fails, and and/or is and (&), the record is rejected. Otherwise, 

tests are continued until one of these criteria is met, or until there are 
no more tests. 
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Use next record also instructs the process to use the next record also, if 
the first is selected. This parameter is needed when more fields are 
called than fit in an item processing record. 

The Test/Move Directive Groups 

The rest of the form contains ten identical groups of fields that are tests 
or move directives. They are implicitly numbered from 0 to 9. These entries 
are used to process each line of the incoming data. 

First in each group are fields to test the data at a specified byte offset 
position for a specified value, as described above. If the test is true, or if 
there is no test, the instructions in the move directive are followed: the 
literal in the then field is inserted into the take, followed by the specified 
count of characters at the specified position, handled as specified by the 
code in the type field, followed by the literal in the and field. 

There are five data types: 

0, [blank] move the text until «;» (semicolon) 

1 the same as 0, but strip leading fixed space (common¬ 
ly used for non-numeric data) 

2 convert numbers and fractions 

3 the same as 2, but strip leading fixed space (common¬ 
ly used for numeric data) 

4 move the entire record to the line 

Continuation Code 

The final field is a continuation indicator, which acts somewhat like the 
continuation indicator in the mask bit tests. The continuation code is acted 
on only if the test is true or there was no test. 

The following continuation codes are supported: 

0 Go to group 0 

1 Go to group 1 

2 Go to group 2 


9 Go to group 9 

& Then (then if) 

! quit 

If the test was true: Continuation codes 0-9 mean, “Go to test n for the 
next test.” The ampersand «&» (then) means “Go to the next field,” while 
the exclamation point «!» means “Terminate processing with this record.” 

If the test was false: If the continuation code is anything other than the 
ampersand, the next group is tested. If the continuation code is the amper¬ 
sand, the process skips to the next group with continuation field other than 
the ampersand and tests the group immediately following this. 

DSTOCKS Error Messages 

“Bad debug file name”—Correct your parameter string. 

“Bad move type in proc”—An incorrect move type entry has been made in 
the digital stocks item processing list. Enter correct move type. 

“Basket name missing from [header]”—The basket name of the digital 
stocks header processing record is missing. Enter correct basket 
name in header processing record. 
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“Bad next code in proc”—An incorrect next code has been entered in the 
digital stocks item processing record. Enter the correct next code. 

“Bad number type in proc”—An incorrect number type has been entered in 
the digital stocks item processing record. Enter the correct number 
type. 

“Bad relation in proc”—An incorrect relation has been entered in the digital 
stocks item processing record. Enter the correct relation. 

“Bad transaction count”—The buffers have been sensed in an incorrect 
sequence. 

“Can’t delete header”—Story is not aborting properly. 

“Can’t find [item]”—There is a record missing from the Configuration file. 
Add the correct record to the file. Item 72 indicates that a header 
processing file cannot be found, while Item 73 indicates that an item 
processing file is missing. 

“Can’t open [file name]”—Either the file does not exist or you do not have 
the authority to access it. 

“Contains bad fraction”—An incorrect fraction has been recorded or the 
Universal Multiplexer is sending erroneous information. The wire ser¬ 
vice must make required corrections. 

“Duplicate portion received”—Data buffers have been received out of 
sequence. The wire service must make the required corrections. 

“I/O failed to [file name]”—There has been an irrecoverable error. 

“Illegal configuration file specified”—An improper Configuration File has 
been specified. Enter correct Configuration File name as the “in” file. 

“Illegal number in proc”—An illegal number has been entered in the digital 
stocks item processing record. Enter the correct number. 

“Invalid ppu name”—An invalid Universal Multiplexer has been specified 
in the parameter string. Enter correct the Universal Multiplexer name. 

“Keyposition failed to [item]”—The data file is faulty or the wrong file has 
been specified. 

“Missed begin of take [item name]”—This error message works in con¬ 
junction with “Missed end of take,” “Missed portion of take” and “Du¬ 
plicate portion received.” A buffer sequencing error has been sensed 
or the Universal Multiplexer has been restarted. Contact your System 
Manager. The wire service must make the required corrections. 

“Missed end of take [item name]”—This error message works in conjunc¬ 
tion with “Missed begin of take,” “Missed portion of take” and “Dupli¬ 
cate portion received.” A buffer sequencing information error has 
been sensed or the Universal Multiplexer has been restarted. The 
wire service must make the required corrections. 

“Missed portion of take [item name]”—This error message works in con¬ 
junction with “Missed begin of take,” “Missed end of take,” “Missed 
portion of take” and “Duplicate portion received.” A buffer sequencing 
information error is sensed or the Universal Multiplexer has been 
restarted. The wire service must make the required corrections. 

“Processing name missing”—Processing name is missing from parameter 
string. Enter the correct processing name. 
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“Saved with errors”—The story has been saved with errors. The number 
of errors is stored in the spell'errors field. 

“Stop request from [terminal]”—The system has received a stop request 
from the named terminal. 

“System must be specified”—No system has been named in parameter 
string. Enter correct system name. 

“Waiting for [process name]”—System is waiting for a process to become 
effective. 

“[Take number] was aborted [item]”—The named story was not accepted 
by the system. 

“Wrong ppu channel specified”—Incorrect Universal Multiplexer channel 
is specified in parameter string. Enter the correct Universal Multiplex¬ 
er channel. 

“warning: Device is not a ppu” —Device specified in parameter string is 
not a Universal Multiplexer. Enter correct device name. 
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APPENDIX C 

Spellbinder/SPEDIT 

This appendix is directed to the user who is responsible for checking the 
spelling of stories or classified ads through the combined use of the 
Spellbinder™ and spedit processes. (The applications described herein 
apply to editorial, advertising and word processing systems. However, the 
term “story” is used throughout in reference to a take.) Before proceeding, 
it is important for the user to understand the intent and application of these 
processes. 

System/55 uses the complete Webster’s New Collegiate Dictionary 
(©1980 by G. & C. Merriam Co.) both for hyphenation and for performing 
spelling checks with the Spellbinder process. The dictionary is under the 
control of your site’s Dictionary Manager, who may add words and abbrevi¬ 
ations to suit your needs. 

There are two ways in which the Spellbinder process may be run: as 
“Spellbinder” and as “Spellbinder/SPEDIT,” the second being the subject of 
this manual. The advantages of each are examined below. 

Spellbinder 

This is a simple method enabling individual users to check the spelling 
of words in their own stories. It is executed with Icmdi 0 (hyphen) while 
viewing a story. 

Spellbinder is a trademark of System Integrators, Inc. The words “Spell¬ 
bind,” “Spellbinding” and “Spellbound” are used throughout this appendix 
to describe the Spellbinder process. 

Advantages: 

• Easy to use. The user does not require access to any utility processes, 
nor is any special knowledge or experience required. 

• Immediate results are available. A “Spelling Error Synopsis” is pre¬ 
sented at the beginning of the story when Spellbinder has completed. 
The user can see all spelling errors at a glance without having to scan 
the whole story. The standard text editing functions are used to correct 
the errors. (A udk can be written to help with this process.) 

• The reporter or editor may submit a story with perfect spelling for publi¬ 
cation. 

• Best for correcting short to medium-size stories or localized changes to 
a large story. 

• Fastest method of running Spellbinder on an individual story. The 
speed, of course, is entirely dependent on system activity—fast during 
low-demand periods, much slower at deadline time. Be aware that 
Spellbinder must check every word in the story, so short stories are 
processed faster than long stories. 

• Does not need to take the time to update the spedit error word list. 
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• The status of the story with regard to Spellbinder is carefully maintained 
by the system in the header fields «spell'date», «speli/time», 
«spell~errors» and «spell"status». The user can monitor the num¬ 
ber of errors. The status field tells whether the story has been Spell¬ 
bound, or whether editing changes have been made since Spellbinder 
was run. 


Spellbinder/SPEDIT 

This is a batch processing approach to spelling verification and correc¬ 
tion. It is designed for processing large volumes of text as fast and as 
efficiently as possible. This method, which employs the Icmdi |~=~| execu¬ 
tion of Spellbinder for checking spelling and the spedit process for correct¬ 
ing misspelled words, is the subject of this appendix. 

Advantages: 

• Spelling corrections may be made the responsibility of a user who is a 
good speller and has a talent for finding errors. Many users do not notice 
their own errors or those of others. This is possibly the most positive 
aspect of this method. By the nature of his task, the spelling editor is 
also an arbiter, along with the Dictionary Manager, of the newspaper’s 
spelling policy, determining whether the use of certain questionable, 
objectionable or slang words will be permitted. 

• The authority to run the spedit process can be restricted. 

• Long stories, and large numbers of stories may be processed quickly 
and efficiently, making them ready for publication sooner. 

• The user does not have to wait for the spelling of each story to complete 
before continuing. The spelling editor may queue a number of stories for 
Spellbinder and access them with the spedit process as they complete. 

• Multiple occurrences of the same obvious error word may be quickly 
corrected without stopping at each word. 

• Less obvious errors may be viewed in context—in a “window” mode—so 
that the precise correction can be determined for each occurrence. 

• By okaying words, the user can tell Spellbinder not to flag specific words 
as errors. This allows proper names, made-up words, slang, and [inten¬ 
tional] error words in quotations to be okayed on a story-by-story basis. 

• The status of the story with regard to Spellbinder is carefully maintained 
by the system in the header fields “Spell" date», «spell"time», 
"Spell'errorS" and «spell"status». The user can monitor the num¬ 
ber of errors, and when they have all been corrected with the spedit 
process the count is lowered to zero. The status field tells whether the 
story has been Spellbound, or corrected, or whether editing changes 
have been made since Spellbinder was run. 

• Any user can display a header form or a list which will tell whether or not 
a story is error-free, or has yet to be processed. Editors can see that, 
with regard to spelling, their pages are ready to be released. 

• Directories may be filtered to list stories with specific spelling statuses. 

• The publication can be confident of publishing an error-free product. 
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Using Spellbinder and SPEDIT to the Best Advantage 

You will develop your own procedures for processing copy for spelling. 
We offer some suggestions to start you thinking. 

There are two forms of the Spellbinder/SPEDIT command. The first level 
command— I cmdI 1~=1—is normally used to spell stories from a directory. 
The second level command— I cmdI Q [=3 —checks the spelling and then 
displays (or redisplays) the take so the number of errors may be noted in 
the header. 


Editorial Applications 

It is recommended that stories be spelled from a directory with the first 
level command. Directory filtering provides a distinc t advantage. Yo u may 
define directory methods for yourself with |cmd| □ 0 through | cmd ] 
□ [o] to suit your particular needs and desires. This will enable you to 
access special directories quickly. 


You can display a directory of all the stories in a basket or a desk that 
are being published on a particular date, but do not have a spelling status 
of «c» (Spellbound and corrected; checking for this “not” condition requires 
a directory method take—see Directory Filtering manual, S55-016). Or you 
can restrict the directory to a particular publication date and sec¬ 
tion/page/edition. 



It is probably most useful for you to direct your attention to stories that 
have been released («select release'status = r») but have not yet 
been Spellbound and corrected («select spell'status <> c»). The 
editing of such stories has been completed and duplicate Spellbinder 
processing is avoided. 


Follow these steps: 


1. Display the filtered directory that suits your requirements. 

2. Execute IcmdI f~=~l on all of the stories in the directory. A udk can do this 
swiftly. 

All of the stories will have been submitted to the spell process. 

3. Execute spedit from your menu of processes or through the Sll Com¬ 
mand Interpreter. 

The first of the stories will be listed in your directory of Spellbound 
stories; if not, wait several seconds and display the directory again. You 
may begin to correct the first story immediately. Each time you return to 
the directory, more completed stories will be waiting for your attention. 

This assembly-line technique will save you from ever having to wait for 
Spellbinder to complete (unless the first story submitted is unusually long). 
With a little experience, you can correct the stories quickly with spedit. 
When production personnel see that they have no errors, they may begin 
to film them (if that is your procedure). 


Recommendations for Learning to Use SPEDIT 

Before using spedit on live stories or ads, create some practice takes 
by copying wire stories. 

Introduce a number of spelling errors into your practice stories. Then run 

Spellbinder on each story with [cmd] [=], execute spedit ^“dze 
then safely experiment with the various spedit commands and familiarize 


/ 
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yourself with the process. Once you have corrected the stories, go back to 
the takes and see how spedit edited them just as you instructed. 

Try using the second and third level editing commands ( ICMDi n [f] and 
IcmdI [7] [I]) until you gain confidence. 


What Not to Expect of Spellbinder 

Spellbinder can flag words and abbreviations that are not in the diction¬ 
ary and words that have been flagged as questionable (archaic spelling), 
objectionable, wrong case, slang or words requiring special treatment. 
However, this feature is not a replacement for good copy editing, nor is it a 
crutch for sloppy spellers and grammarians. 

Spellbinder cannot find syntax and usage errors. Only a careful editor 
can, for example, determine whether “nations” should be “nation’s” or 
“nations’” if the word is otherwise spelled correctly. Spellbinder cannot 
know that “affect” was misused and that the proper word in this instance is 
“effect.” 
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Running Spellbinder/SPEDIT 


There are two forms of the Spellbinder/SPEDIT command 
level) and “wait” (2nd level). 


-“no wait” (1st 


Spellbind No Wait 

Enter Icmdi f=1 to Spellbind a story. This is the most commonly used 
form of the command. It may be executed under the following circum¬ 
stances: 

1. With the cursor resting on a story in a directory. The mnemonic charac¬ 
ter used for the command (« = ») blinks at the position of the cursor. If 
you wish, you may move the cursor to a blank column to prevent the 
blinking indicator from replacing a character in the display. This is the 
most efficient method of Spellbinding large numbers of stories quickly. 

2. From an idle state or with the cursor not pointing at an item in a 
directory. This prompt is displayed: 

Spell check story _ 

Enter a story name followed by IcmdI . 

3. While a story is displayed. The blinking message “Checking Spelling” is 
displayed on the status line. 


Spellbind and Wait 

Enter [cmdI □ [H] from an idle state, with the cursor pointing at an item 
in a directory, or while a story is displayed. The story is Spellbound, the 
results are filed, an oops or audit copy is created, and then the story is 
displayed beginning with the last line edited (by any user). 

Spellbinder also updates the header to display the number of errors: 

SPELLBINDER run on 12/12/81 at 14:17:30 with 7 errors. 


If the story has been edited since it was processed by Spellbinder, it 
may be noted in the header following the error synopsis: 

(Story was subsequently edited) 
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Running SPEDIT 

A story processed by Spellbinder is available for editing by other users 
at all times with two exceptions: while it is being processed by Spellbinder 
and while corrections are being applied to the story during editing with 

SPEDIT. 

Stories which are being processed by Spellbinder are normally unavail¬ 
able for editing for only a few moments. Attempting to edit the story during 
that time will log the message “Submitted to spell by username”. Once 
“Spellbinding” is complete, the story is available for editing by all those who 
have access to it. Spellbinder processing information may be displayed in 
the header. 

The spelling editor should always use a header form which displays the 
Spellbinder status field (Spell'status). It is possible for a story to be 
edited between the time that Spellbinder is run and the time at which it is 
edited with spedit, so this information must be visible. Please see “Status 
Flags in the Story List,” for a description of the possible contents of this 
field. 


Starting the Process 

You can execute spedit from Sll Command Interpreter. 

Exiting the Process 

To exit spedit, enter IcmdI [71 or IcmdI IT1. 

Displaying the SPEDIT Revision Date 

fcMDl \¥\ displays the spedit revision level on the status line. For 
example: 

Program revision level: S0082.E02.002 (004) 

The Help Command 

IcmdI [h] lists the available spedit commands (see Table C-1). If the 
cursor is resting on a command in the list, IcmdI [h] displays a more 
detailed description of that command. Executing IcmdI 03 again at that 
point returns to the list of commands. 

Table C-1 on the following page contains a list of the available com¬ 
mands and a brief description of each. 
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Table C-1 

List of SPEDIT Commands and Their Descriptions 

|CMD| [Hi 

List commands or give detailed description of a command. 

|CMD| [d] 

List directory of stories that have been Spellbound by current 
user 

(CMDl n [dI 

List stories Spellbound by another user 

[cmdI [71 Id! 

List stories Spellbound by all users 

[cmd! (w[ 

List error words of a story (except those flagged «o» or «a») 

[cmdi n m 

List only unflagged error words 

[cmd[ [71 |w[ 

List all error words 

[cmd[ 0 

Print the error word list of a story (except those flagged «o» 
or«A». 

[CMD[ n [Pi 

Print only unflagged error words. 

[cmd] [71 [p| 

Print all error words. 

1CMD| [n! 

List error words of the next story 

|CMD| [cl 

Correct the word 

(CMDl H [Cl 

Correct all unflagged words from cursor down 

|cmd| [Vi 

Flag the word for viewing in context 

[CMDl Q 0 

Flag all unflagged words from the cursor down 

[CMDl 0 

Unflag the word 

[CMDl □ 0 

Unflag all words from the cursor down 

fCMDl 0 

Okay the word to remove it from consideration 

[CMDl Q (pi 

Flag all unflagged words as okay from the cursor down 

|cmd| 0 

Advise the Dictionary Manager to put the word in dictionary 

(CMDl Q 0 

Flag all unflagged words for referral from the cursor down 

[CMDl 0 

Edit the story using the error word list 

|cmd1 Q 0 

Edit story, pause at end 

(CMDl 0 0 

Edit story, pause on unflagged words, «v» flagged words, 
and at end 

(CMDl Q] 

Ignore changes made to the story 

(CMDl 0 

List dictionary words 

[CMD( Q 0 

Re-display dictionary prompt for editing; when editing story, 
prompt is prefilled with the word being viewed 

(CMDl 0 

Return to previous list 

(CMDl Q 0 

Release queued proofs 

(CMDl 0 

Kill all the error word records of a story 

[CMDl 0 0 

Kill entries of stories with zero errors from cursor down. 

[CMDl 0 0 

Kill all entries in Spellbound story list from cursor down 

|CMD| [¥] 
(CMDl □ or 

Display spedit revision level 

Icmd| Q 

Exit from spedit 
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SPEDIT Lists 

In addition to the list of commands, three other lists may be displayed: a 
list of Spellbound stories, a list of error words in a story, and a list of 
dictionary words. Each is discussed in this section. 

The List of Spellbound Stories 

When spedit is executed, the message “spedit starting” is displayed on 
the status line, spedit must open a number of files for you; this may take 
several seconds. Next a list of all stories that you (the signed-on user) 
have Spellbound is displayed. A sample list is illustrated in Figure C-1. 

Other directories, for all users or for a specified user other than the 
signed-on user, are also available. 


List of Spellbound Stories 11/03/81 16:10 

Status Story Name _ Words Errors User Date 

Time 


s 

prime rate 

205 

3 

CHRISTOPHER 

11/05 

10: 38 

s 

iran 

149 

8 

CHRISTOPHER 

11/05 

9: 00 

s 

arms buildup 

512 

16 

CHRISTOPHER 

11/05 

8: 04 

s 

new ss cuts 

509 

6 

CHRISTOPHER 

11/05 

8: 03 


Figure C-1. List of Stories Processed by Spellbinder. 

Times displayed in the list indicate when Spellbinding was completed. 
The most recent time is listed first. When a story is corrected with spedit, 
the time of correction is listed. 

You may get a list of Spellbound stories at any time, except while a story 
is being edited by spedit. All lists contain only those stories to which you 
have access. 

List Stories Spellbound by Signed-on User 

IcmdI [d] displays a list of stories that have been Spellbound by the 
signed-on user. 

List Stories Spellbound by Another User 

|cmd| □ [d] displays the following prompt to list stories by another user: 

List stories for user __ 


Complete the prompt with the name of the user, and press IcmdI . 

List All Spellbound Stories 

l CMp | Q] 0 lists the stories of all users. 


Status Flags in the Story List 


Three flags may appear in the status field of the story list, each of 
which is shown in Figure C-2. 

«s»—the story has been processed through Spellbinder but corrections 
have not been applied through spedit. 


«c» 


remains nthe apP " ed thr ° Ugh SPED,T but the story 
remains in the list because error words have been flaqaed as “okav ” 

or for referral to the Dictionary Manager 99 ° kay ’ 
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«*» 



—the story has been edited since it was processed by Spellbinder. In 
order to Spellbind the story again to pick up any errors which may 
have been introduced, you must exit spedit. Attempting to spell the 
story ( IcmdI I = I ) from the list of Spellbound stories will log the 
message “Illegal command.” 


List of 
Status 

Spellbound Stories 
Story Name Words 

Errors 

User 

11/03/81 16:10 
Date Time 

S 

prime rate 

205 

3 

CHRISTOPHER 

11/05 10:38 

C 

iran 

149 

0 

CHRISTOPHER 

11/05 

9:30 

* 

arms buildup 

512 

16 

CHRISTOPHER 

11/05 

8: 04 


Figure C-2. Status Flags in the Story List. 


Cursor Movement in the Story List 

The cursor may be moved from item to item in the list of stories by 
pressing the appropriate directional key. It is not necessary to press the 
icursorI key. The spacebar and IreturnI move the cu rsor t o the next 
item in the list; 1 backspace! moves to the previous item. |tab| alternates 
the cursor between the status line and the previous position in the list. 


Error Word Lists 


Each story in the list of Spellbound stories has a corresponding list of 
error words which were flagged by Spellbinder. The list is alphabetical by 
error word. Cursor movement is the same as in the story list. 


List Error Words 

Icmdi [wl lists all words for the indicated story except those previously 
flagged «o» (okay) or «a» (referred to Dictionary Manager). This command 
is most useful for displaying error word lists before words have been 
flagged. 

From a list of Spellbound stories, po int the cursor at the story whose 
error word list you want displayed. Enter |cmd| [w] to display that list. 

When the cursor is not pointing at a story, executing Icmdi [w] prompts: 

List error words for story _ 


Complete the prompt with the name of a story and press |cmd| . The list 
is displayed as illustrated in Figure C-3. 


Spellbinder error 

words for story 

‘prime rate' 11/05/81 16:12 

3 error (s) 205 

word(s) 203 hit(s) 1.42 secs 

CHRISTOPHER 11/05/81 10:38 


Act Reason Cnt 

Word 

Correction 

1 

creditworthy 


1 

indicater 


1 

indicaters 


3 Item(s) listed 




Figure C-3. Error Word List for Story “prime rate”. 
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List Unflagged Error Words 

ICMDI □ [w] lists only unflagged words in the error word list; that is, those 
that have not been acted upon. 

List All Error Words 

IcmdI [7] [W] lists all words; useful for displaying the remaining “okayed” 
and referred words after corrections have been made to the story. 


List Error Words of Next Story 

IcmdI [nJ lists the error words of the next story in the list of Spellbound 
stories without going back to the list. The mode of display is the same as 
for the previous story. 


Information in Error Word List 

The first line of the error word list indicates the name of the story to 
which the list applies. The second line tells the number of errors found in 
the story, the number of words in the story, the number of “hits” made by 
Spellbinder (the process maintains in memory a dynamic list of most 
frequently used words) and the length of time taken to complete the 
spelling check. The third line contains the name of the user who submitted 
the story to Spellbinder, and the date and time at which it was done. 

The columns headed act, reason, cnt, word, and correction con¬ 
tain information about the error words: 


ACT 

REASON 


CNT 

WORD 

CORRECTION 


Flags indicating the action taken for this particular er¬ 
ror word: «blank», «c», «v», «o», «a». 


The reason that this word was flagged by Spellbinder. 
Flags from the dictionary list may appear in this col¬ 
umn, plus an additional flag, «caps», which indicates 
an error in the capitalization of the word. See “Flags in 
the Dictionary List” at the end of this section. 


The number of times this error word occurred in the 
story. 


The error word found by Spellbinder. 

The correction provided by the user with IcmdI [cl. 


Return to Story or Word List 

To return to the same position in the previous list, execute IcmdI [r]. If 
you list Spellbound stories, then call an error word list, IcmdI 
[HI again will log the message: “Can return no farther than story list.” 


Obtaining a Proof of an Error Word List 

Normally, a proof is necessary only when you wish to discuss it with 
another user, or for some reason you wish to keep a record of the spelling 
errors in the take. 


|cmd| [pj produces a hardcopy of an error word list. When a directory of 
Spellbound stories is displayed, position the cursor on the story for which 
you want a proof and enter IcmdI [pj. 


Executing IcmdI [p] while an error word list is displayed generates a 
proof of that list. 
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When a story is not displayed, IcmdI 0 gives the following prompt: 

Proof error words for story _ 

Complete the prompt with the name of a story and press IcmdI . 

Any of the lists that may be generated by the IcmdI Iwl options may be 
produced in hardcopy form; for example: 

IcmdI [p] lists all error words except those flagged «o» or «a». 

IcmdI □ [p] lists only unflagged words. 

IcmdI 0 0 lists all error words. 

Releasing Proofs 

Whenever a proofing command is executed, the word list is written to 
the proof location in your user profile. The proofs are not actually sent to 
that location, however, until you exit spedit. 

To release them before exiting spedit, enter IcmdI 0 0. All queued 
proofs are released immediately to the location specified in your user 
profile. 


Listing the Dictionary 

IcmdI 0 lists the words in the Dictionary. When the cursor is not pointing 
at a word in the error word list, a blank prompt is supplied: 

Word _ 


Enter the word with which you wish the listing to begin and press IcmdI . 

Entering an asterisk (*) following the last character of the word will limit 
the dictionary list to words beginning with the characters preceding the 
asterisk. This is helpful in finding a word when you are not sure of the 
spelling. Simply enter the characters you are sure of, followed by an 
asterisk, and press IcmdI to display a list of words containing those initial 
characters. 

Entering an exclamation point (!) following the last character of the word 
will limit the dictionary list to that single word. 

When the cursor is resting on a word in the error word list, the prompt is 
prefilled with that word. You may then edit the prompt as necessary to 
obtain a useful dictionary listing. 

IcmdI □ 0 displays the previous successful prompt for editing. 

When IcmdI 0 0 is executed while editing a story, the prompt is filled 
with the word being viewed. 

Flags in the Dictionary List 

The flags that may be displayed in the dictionary list, and in the reason 
field of the error word list, are explained below: 

«blank» The word was not found in the dictionary. This flag 
may occur on proper nouns not included in the dictio¬ 
nary, as well as on misspellings. 

questn This spelling is flagged as questionable or archaic. For 
example, “cancelled” instead of “canceled.” 
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object The word is flagged in the dictionary as objectionable; 
for example, an obscenity. 

slang The word is flagged in the dictionary as slang. 

specl The word is flagged in the dictionary as one requiring 

special attention. For example, a foreign word that 
should be set in italic or a word requiring a trademark 
acknowledgement. 

«*» The word has no hyphenation points. 

" = » The word contains non-alphabetic characters. 

Figure C-4 shows a sample dictionary listing with words flagged as 
questionable and with no hyphenation points. 


Dictionary Listing (adaptor) 

11/06/81 10: 22 

Type H A 

Word 


Questn 

adap tor 


* 

Adar 



ad ax i al 


* 

ADC 


...etc. 




Figure C-4. Dictionary Listing. 
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Specifying Corrections 
in the Error Word List 

The recommended procedure for correcting spelling errors is as follows: 

1. Display the error word list for the story. 

2. Beginning at the top of the list, for each word take no action (implied 
approval of the word), or one of the following actions: 

a. Correct the spelling of the word with Icmdi [c] (sets act flag to 
«c»). 

b. Specify the word for viewing in context with |cmd| [v] (sets act flag 
to «v»). 

c. Refer a word you think is correctly spelled to the Dictionary Man¬ 
ager with fcMDl [a] (sets act flag to «a»). 

d. Okay (all occurrences) of the word with Icmdi [o] (sets act flag to 
«o»). 

3. Edit the story with fcMDl \e\ (see Section C-6) or one of its variations. 
None of the corrections will have any effect until you do this. 

An alternative to step 2—and a faster method depending on the circum¬ 
stances—is to read through the error list, decide which action you will take 
for most of the words, flag all of the other words with the alternative 
actions, and then return to the top of the list and execute the second level 
of the command which will perform your “primary” action (okay, advise, 
correct, view in context). 

Correct Spelling of Word 

Icmdi [c] displays a prompt (Figure C-6) in which to correct the spelling 
of the word at which the cursor is pointing in the error word list. 


Spellbinder error words for story ‘prime rate' 11/05/81 16:15 

3 error (s) 205 word(s) 203 hit(s) 1.42 secs 

CHRISTOPHER 11/05/81 10:38 

Act Reason Cnt Word Correction 

1 creditworthy 
1 indicater 
1 indicaters 

3 Item(s) listed ___ 

Figure C-5. Error Word List for Story “prime rate”. 

In Figure C-5, the error word list contains only obvious misspellings or 
typographical errors, so all words can be marked for correction. You may 
research correct spellings with |cmd| (yJ- 

When IcmdI [c] is executed, the prompt shown in Figure C-6 is dis¬ 
played. The word is picked up from the error word list and displayed in the 
correction field ready for you to make your correction. 


C.13 

























Specifying Corrections in the Error Word List 


Editorial Manager’s Manual 


Word: creditworthy 

Correction: creditworthy 

1 

creditworthy 

1 

indicater 

1 

indicaters 

3 Item(s) listed 



Figure C-6. Error Word List With Correction Prompt Prior to Correction. 


Specify the correction by typing the correct spelling of the word (“credit¬ 
worthy”) in the correction field of the prompt, and press [cmdI . The 
correction is displayed in the error word list and you may repeat the 
process for the next word. 

If you press Icmdi without making a correction, the message “No correc¬ 
tion made” is logged on the status line. 

You may remove the prompt by pressing IcancelI . The word will not be 
corrected and will not be flagged in the error word list. 


Word: indicater 

Correction: indicator 

C 1 

creditworthy 

credit-worthy 

1 

indicater 


1 

indicaters 


3 Item(s) listed 




Figure C-7. Error Word List With Correction in Progress. 


Note that in Figure C-7 the spelling of “indicator” has been been correc¬ 
ted in the prompt. A “c” has been inserted in the act (action) field for 
“credit-worthy” and the correct spelling of the word appears in the correc¬ 
tion field of the list. 

Each execution of Icmdi [c] displays a similar prompt for each error word 
in the list. The completely corrected list would appear as illustrated in 
Figure C-8. 


Spellbinder error words for story ‘prime rate' 

3 error (s) 205 word(s) 203 hit(s) 1.42 secs 

CHRISTOPHER 11/05/81 10:38 

Act Reason Cnt Word Correction 

credit-worthy 


11/05/81 16:22 


C 

C 


creditworthy 

indicater 

indicaters 


3 Item(s) listed 


indicator 

indicators 


Figure C-8. Error Word List With Corrections Complete. 


I.Q. MD I □ [cl displays a prompt to correct the spelling of an unflagged 
word in the error word list and then automatically moves to the next 
unflagged word until it reaches the end of the list, displaying the prompt for 
each. 
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Flagging Words for Viewing in Context 


IcmdI [v] flags the error word at which the cursor is pointing for viewing in 
the context of the story. (Viewing takes place when the story is edited.) 
This is useful when it is not readily apparent what the corrected spelling of 
the word should be. For example, in the error word list in Figure C-9 “iss” 
could be “is” with an extra “s”, or perhaps it should be “its” or “it’s”. To be 
certain we need to see the word in the context of the story. 


Spellbinder error words for story ‘new ss cuts' 11/05/81 16:31 
6 error (s) 506 word(s) 503 hit(s) 4.77 secs 

CHRISTOPHER 11/05/81 8:03 

Act Reason Cnt Word Correction 

1 J. J 

1 Rostenkowski 
1 elminate 

1 iss 

2 legslation 
1 resusitate 

6 Item(s) listed 

Figure C-9. Spellbinder Error Word List. 

In Figure C-10, some words have been flagged for correction and others 
for viewing in context. 


Spellbinder 

error 

words for story ‘new ss cuts' 11/05/81 16:35 

6 error (s) 

506 

word(s) 503 

hit (s) 4.77 secs 

CHRISTOPHER 

11/05/81 8:03 


Act Reason 

Cnt 

Word 

Correction 

V 

1 

J. J 


V 

1 

Rostenkowski 


C 

1 

elminate 

eliminate 

V 

1 

iss 


C 

2 

legslation 

legislation 

C 

1 

resusitate 

resuscitate 

6 Item(s) listed 




Figure C-10. Spellbinder Error Word List Following Flagging. 



IcmdI □ [v] flags all unflagged words from the cursor to the end of the 
error word list. When a story is edited with IcmdI [7] [e] , all unflagged words 
will also be viewed in context. 


Okaying Words 

It is only necessary to okay words if it is likely that Spellbinder will be run 
on the story again, (spedit maintains a list of words you have okayed so 
they will never be listed for that story again.) This applies especially to 
permanent stories that continue to be edited and republished. For average 
news stories that are published immediately following editing, okaying 
words is an unnecessary task. In such cases, simply ignoring words in the 
list (leaving them unflagged) implies that they are okay for this version of 
the story. 


IcmdI \o\ okays the word at which the cursor is pointing. This command 
is helpful when a story contains words which, although not in the dictio¬ 
nary, are nonetheless acceptable. When such a word is flagged with 
IcmdI El, and the story is subsequently Spellbound, the wor d is not 
checked or counted as an error, and it will not appear when using IcmdI [W1 
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to list error words (it can always be displayed by using IcmdI [7] [w]) ([cmd| 
gl can be used to okay a word and refer it to the Dictionary Manager; see 
Adding Words to the Dictionary Referral List.”) 

[£M2J □ 0 flags all unflagged words from the cursor to the bottom of the 
list. 


Spellbinder 

error 

words for 

story ‘iran 1 11/05/81 16:41 

8 error (s) 

149 

word(s) 112 hit(s) 10.96 secs 

CHRISTOPHER 

11/05/81 8:03 


Act Reason 

Cnt 

Word 

Correction 

0 

1 

Bani-Sadr 


0 

1 

Behbahan 


0 

1 

Kayhan 


0 

1 

Kurds 


0 

1 

Nowshahr 


0 

1 

Oshnaviyeh 


C 

1 

officialy 

officially 

C 

1 

personell 

personnel 

8 Item(s) listed 




Figure C-11. Spellbinder Error Word List Following Flagging. 

In Figure C-11, the proper names flagged by Spellbinder in story “iran” 
have been okayed. When the story is edited, the corrections will be applied 
to the story and okayed words will be preserved for use by Spellbinder As 
long as this error word list is not purged, the words will not be checked or 
counted as errors when the story is subsequently Spellbound. 

In effect the okayed words act as a temporary addition to the dictionary 
as long as the story is left in the spedit story list. y 


Updated 

Status 

o 

story 'iran' 
Story Name 

Words 

Errors 

User 

11/05/81 16:45 
Date Time 

b 

p 

prime rate 

205 

3 

CHRISTOPHER 

11/05 10:38 

o 

iran 

149 

0 

CHRISTOPHER 

11/05 16:42 

b 

arms buildup 

512 

16 

CHRISTOPHER 

11/05 8:04 


Figure C-12. List of Spellbound Stories. 

When words in the error word list have been okayed the story is not 

fr0m the liSt 0f Spellbound Stories following editing 
Instead, its status is changed from «s» to «c» (see Figure C-12) and the 

nkavpH° rd H? U t nt IS chan9ed t0 <<0>> ( zer °)- 0n| y corrected stories with 
H° r ♦ ' apf f ar in the list of Spellbound stories under status «c» 
Corrected stories with no okayed words are removed from the list. 
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♦ 




The okayed words may still be listed and changed by executing |cm d] 
□ E3. as shown in Figure C-13. 


Spellbinder 

error 

words for story ‘iran’ 11/05/81 16:50 

0 error (s) 

149 

word(s) 0 

hit (s) .51 secs 

CHRISTOPHER 

11/05/81 16:42 


Act Reason 

Cnt 

Word 

Correction 

0 

1 

Bani-Sadr 


0 

1 

Behbahan 


0 

1 

Kayhan 


0 

1 

Kurds 


0 

1 

Nowshahr 


0 

1 

Oshnaviyeh 


6 Item(s) listed 




Figure C-13. Spellbinder Error Word List Following Editing. 

Note: The okayed word list maintained by spedit is refere nced o nly when 
you use the wait and no-wait spedit commands— |cmd| (j=] and 
[cmdI □ [H]—to execute Spellbinder/sPEDiT. It is not referenced 
when Spellbinder is executed with |cmd| □. The two forms of 
Spellbinder are not interchangeable. 

Adding Words to the Dictionary Referral List 

In the case of the proper names in the example above, we may mark 
those which will be occurring fr equen tly in stories for possible inclusion in 
the dictionary. To do so execute [cmd]0. 

Spellbinder error words for story ‘iran' 11/05/81 17:00 

0 error(s) 149 word(s) 0 hit(s) .51 secs 

CHRISTOPHER 11/05/81 16:42 

Act Reason Cnt Word Correction 

A 1 Bani-Sadr 

0 1 Behbahan 

0 1 Kayhan 

0 1 Kurds 

0 1 Nowshahr 

0 1 Oshnaviyeh 

6 Item(s) listed ___ 

Figure C-14. Spellbinder Error Word List With Word Flagged for Dictionary Referral. 

In Figure C-14, “Bani-Sadr” has been flagged for inclusion in the Dictio¬ 
nary Referral List available to the Dictionary Manager. A previously okayed 
word may be re-flagged by positioning the cursor at the word and execut¬ 
ing [cmdI 0. The word is added to the referral list as soon as IcmdJ 
0 is executed. There is no need to edit the story to do this. 

Aside from their addition to the Dictionary Referral List, word s flag ged 
with IcmdI 0 are treated in the same way as those flagged with I cmd j |oJ; 
they are not checked or counted as errors. 

[cmdI □ 0 flags all unflagged words from the cursor to the end of the 
error word list. 
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Changing Error Word Flags 

The flag for each error word may be changed at any time by positioning 
the cursor at the word and executing the desired command. 

Unflagging Words 

ICMDl Un unflaqs a previously flagged word in the error list. If the story is 
subsequently Spellbound, unflagged words will again be checked and 
included in the error count (unlike those flagged «o» or «a»). 

IcmdI [7] [u] unflags all words from the cursor to the end of the error word 
list. 
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Editing the Story 


Once words have been flagged (or left unflagged) as desired, you are 
ready to apply the changes to the story with an Edit command. When you 
are first learning to use spedit, we recommend that you use^the se cond- 
or third-level commands— [cmdI □ d (Edit Story, Pause at End) or |cmd| 
□ (U (Edit Story, also View Unflagged Words and Pause at End). Either of 
these commands allows you to change your mind about applying the 


changes. 


Editing: Applying Corrections to the Story 

When IcmdI [U is executed, words which have been flagged «c» in the 
error word list are automatically corrected in the story and the message 
“(story name) updated” is displayed. If word s in the error word list have 
been flagged for viewing in context with |cmd| [v], each occurrence of each 
word is displayed as it is encountered in the story. A replacement prompt is 
displayed to allow correction of the word. 

Figure C-15 shows the display of a word in context with a replac emen t 
prompt. Make the correction in the “Replace with” prompt and press [ cmd ]. 
Editing continues through the story until another «v» word is found. 




Found word: iss 

Replace with: iss ____— - : — : -;--— 

2 error words remaining in story 

•new ss cuts' 

Word in context; 

of a package of proposed benefit cuts. 

Instead, House and Senate conferees meeting today 
to fashion final Social Security legislation planned 
to consider a short-term attempt to resuscitate the 
system by mingling i^> three trust funds. 

Under pressure from top Democratic leaders, the House 
Ways and Means Committee rejected a proposal to raise 
the regular retirement age of Social Security beneficiaries 
and change the way cost-of-living increases are calculated. 

Figure C-15. Error Word Viewed in Context of Story. 


Notice that “resusitate”, flagged «c» in the error word list, has been 
corrected to “resuscitate”. 

In Figure C-16, the correction has been entered in the prompt. When 
you press IcmdI . the correction is made to the story and spedit moves to 
the next error word flagged for viewing in context so that it may be 
corrected as necessary. 


The words are not displayed alphabetically as you flagged them in the 
error list. Instead, starting at the beginning of the story, each occurrence of 
any word flagged with «v» is displayed in the order in which it is encoun¬ 
tered in the text. Four lines of text are shown before the line containing the 
error, and four after, to help you to determine the correct replacement. 
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Found word: iss 

Replace with: its _ 

2 error words remaining in story ‘new ss cuts' 

Word in context: 

of a package of proposed benefit cuts. 

Instead, House and Senate conferees meeting today 
to fashion final Social Security legislation planned 
to consider a short-term attempt to resuscitate the 
system by mingling three trust funds. 

Under pressure from top Democratic leaders, the House 
Ways and Means Committee rejected a proposal to raise 
the regular retirement age of Social Security beneficiaries 
and change the way cost-of-living increases are calculated. 

Figure C-16. Error Word Viewed in Context of Story. 

If no correction is necessary, press IcmdI or Ireturni to move to the 
next error word. 

As spedit moves from one error to the next it keeps a running count of 
the errors still to be corrected in the story—for instance, “2 error words 
remaining in story ‘new ss cuts’”. 

When the last word has been corrected, the message “Editing story” 
blinks on the status line of the vdt, informing you that the story has been 
edited and is being filed with the changes, spedit then returns to the 
Spellbound story list as illustrated in Figure C-17, with a confirmation 
message on the status line. If no words in the error word list were marked 
for dictionary referral or as okay, the story is removed from the list of 
Spellbound stories. 


Updated 

story ‘new ss 

cuts' 



11/05/81 16:37 

Status 

Story Name 

Words 

Errors 

User 

Date Time 

S 

prime rate 

205 

3 

CHRISTOPHER 

11/05 10:38 

S 

iran 

149 

8 

CHRISTOPHER 

11/05 9:00 

S 

arms buildup 

512 

16 

CHRISTOPHER 

11/05 8:04 


Figure C-17. List of Spellbound Stories. 


The editing process can be suspended when viewing a word in context 
by pressing icanceli . The error word list is redisplayed and the following 
message is given on the status line: 

Editing suspended: CMD E continues, CMD I stops 

You may then access other spedit commands. To resume the original 
mode of editing, execute IcmdI [e]. Editing can be stopped at any time by 
executing IcmdI Q]. (Press Icanceli first if a correction prompt is dis¬ 
played.) All changes to the story are discarded. 

Edit Story, Pause at End 

Icmd| [T] [1] edits the story and but pauses at the end to allow changes to 
be ignored. The following prompt is displayed: 

End of story. Do you wish to save changes to 'storyname'? 

Press Ireturni to file the story with the changes. 

Press icanceli to ignore the changes. 
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Edit Story, Pause on Unflagged Words 

Icmdi Q] [U displays all unflagged words in context in addition to any 
words flagged with «v». It also performs all the functions of Icmdi HQ. Use 
this command when you wish to view all words, except those flagged «c» 
(the corrections are made when you execute this command), «o» and «a». 


If a word requires no changes you can move to the next error word in the 
story by pressing Icmdi when the prompt is displayed. When all words 
have been corrected or passed over, spedit returns to the error word list 
and gives the following prompt: 

End of story, do you wish to save changes to ‘storyname’? _ 


Press IreturnI to save the changes and update the story. 

Press Icanceli to ignore the changes. 

Ignoring Changes to a Story 

Icmdi [Q ignores all editing changes made to the story when executed 
while editing is suspended. (Suspend editing by canceling the viewing 
prompt.) Editing can be restarted from the beginning of the original story. 
The end-of-story prompt can also be used to ignore changes. 


Purging the Error Word List 

Icmdi [k] kills the error word list for a story. The error word list is removed 
and the story is no longer listed in the spedit story list. A new error word 
list will be created if the story is Spellbound again. This command is useful 
for clearing the story list and eliminating lists of okayed words. The com¬ 
mand may be executed from the list of Spellbound stories, while an error 
word list is displayed, or by completing a prompt. 


In the list of Spellbound stories, point the cursor at the story error word 
list you want to purge and enter IcmdI [k1. You are prompted: 

Are you sure you want to purge errors for STORYNAME? _ 


Answer with IreturnI for yes or IcancelI for no. 

If you respond to the prompt with IreturnI . the error words for that story 
are immediately purged and the story is eliminated from the list. Any 
okayed words which were in the list are also purged and are no longer 
available for referencing by Spellbinder. 

To purge a displayed error word list, enter [cmd| [kJ. The above prompt 
is displayed. To purge the error word list, press IreturnI . The blinking 
message “Purging” is displayed on the status line of the vdt, the list is 
purged and spedit returns to the list of Spellbound stories. 

To cancel the prompt, press IcancelI . 


When a list of Spellbound stories or error words is not displayed, execut¬ 
ing Icmdi [k] displays the following prompt: 


Purge errors for story 


Complete the prompt with the name of a story and press IreturnI . The 
following prompt is displayed on the status line: 


Are you sure you want to purge errors for STORYNAME? 
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Press Ireturni to purge the error word list or IcancelI to remove the 
prompt. 


Purging All Stories With Zero Errors 

When a list of Spellbound stories is displayed, Icmdi □ [kJ purges all 
stories from the list which have zero errors from the cursor down. You are 
prompted: 

Are you sure you want to purge story entries 
without errors starting from story STORYNAME? 


Answer with ireturni for yes, or IcancelI for no. 

This purges all stories which no longer have errors but still have lists of 
okayed words. If you complete the prompt, previously okayed words will be 
listed as errors if Spellbinder is run on any of the stories again. 

Purging All Stories in List 

When a list of Spellbound stories is displayed, Icmdi Q [k] purges the 
error words lists for all stories from the cursor down whether they have 
been corrected or not. You are prompted: 

Are you sure you want to purge ALL story entries 
starting from story STORYNAME? 


Answer with ireturni for yes, or IcancelI for no. 


If the prompt is completed, the directory will be completely cleared 
starting from the position of the cursor. If the list was displayed with Icmdi 
HI, o nly your own stories are cleared. If the list was displayed with 
l CMp l □ III, only those of the specified other user are cleared. However, if 
the list was displayed with IcK^dI □ (dJ, all currently Spellbound story 
error word lists for all users will be cleared. Be very careful. 


Recovering a Story After Editing Has Been Completed 

When you finish editing a story and then realize that some or all of the 
changes should not have been made, you can still recover from your error. 
Exit spedit , edit the story with IcmdI [eH . and recover the previous version 
with |cmd| □ \T}. You may then run Spellbinder on the story again if you 
like. 

If you can’t recall the story name, you may define a filtered directory 
method to display only stories with a Spell Status of «c» that have been 
change d since the date/time you think you made the error. Use [cmdI □ Q] 
through icmdi [7][o]to define your filtered directory. 


SPEDIT Error Messages 

The error messages below may be logged on the status line when 
spedit is started or while the process is running. Where the message 
indicates some system error or a malfunction beyond your control, no 
explanation is offered. Notify your System Manager when those errors 
occur. 
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User Errors 



“Cannot justify”—Justification failed for the take in the system which re¬ 
quires all takes to be justified (a classified system). 


“Illegal except on et/960 or equivalent”—Running on incorrect type of 
terminal. 


“Invalid file name for network”—You are attempting to operate spedit on 
the network with the wrong file name. 

“Must run under Sll vdt Control System”—Running on incorrect system. 

“No startup message found”—The system startup message was not re¬ 
ceived. Start spedit again. If this message is given again, contact 
your System Manager. 

“open failed for [filename]”—Either the file does not exist, or you do not 
have the authority to access it. 


“Outside your jurisdiction”—You do not have sufficient authority to start 
the process or to access a story in the Spellbound story list. 

“Private story”—The story has been flagged “private” and can only be 
accessed by the original user or the owner. 

“Proofing location missing in user profile”—This message is given if you 
request a proof without having a proofing location specified in your 
user profile. 



“Read-only story”—The story has been flagged “read-only” and may not 
be edited. 


“Take not found”—The take has been purged since the list of Spellbound 
stories was last displayed. 


Functional and Programmatic Errors 


“Can’t find xyzz table”—Character set xyzz file is not in the configura¬ 
tion file. 


“Dictionary not found in config” —System configuration file is incorrect or 
incomplete. Contact your System Manager. 

“Dictionary referral file not found in config”— System configuration file is 
incorrect or incomplete. Contact your System Manager. 

"Fatal i/o error in [filename]”—There has been an irrecoverable error. 
Contact your System Manager. 

“Header update process not found”—A. story may not be edited if the 
header cannot be updated. Contact your System Manager. 

“Overseer name not found in config”— System configuration file is incor¬ 
rect or incomplete. Contact your System Manager. 

“Spell story summary file not found in config”— System configuration file 
is incorrect or incomplete. Contact your System Manager. 



u 


Spell error word file not found in config”— System configuration file 
incorrect or incomplete. Contact your System Manager. 


is 


“Super not found in config”— System configuration file is incorrect or 
incomplete. Contact your System Manager. 
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“System description record is missing”—Notify your System Manager. 

“System file not found in config” —System configuration file is incorrect or 
incomplete. Contact your System Manager. 

“Take header file not found in config” —System configuration file is incor¬ 
rect or incomplete. Contact your System Manager. 

“Text read process not found”—Notify your System Manager. 

“Text write process not found”—Notify your System Manager. 

“User file not found in config”— System configuration file is incorrect or 
incomplete. Contact your System Manager. 
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vdt groups—see user groups 
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forwarding 

wire entry hours, A-1.5 
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write level, A-2.7 
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